[aot repositories] add quick fix to turn generated query into manual query annotation

[martinlippert]

Add a quick fix action as a separate code lens section called turn into @Query annotation that takes the generated query from the aot metadata and turns this into a query annotation to allow users to turn auto-generated queries into manually defined ones (via a @Query annotation), e.g. in order for them to fine-tune the query to their needs.

[martinlippert]

Also add a code action that appears on the method declaration (the name and the modifiers, not the whole body) to execute this quick fix, so that users who do not want the code lens to show up can invoke the quick fix code action to do this. But the code action should always be there, independent of whether users want to see the code lens or not.

[BoykoAlex]

@martinlippert I think you meant diagnostic with a quick fix... Code Action don't show up as squigglies under the text... VSCode would show a lightbulb if the cursor is on the text in question and Eclipse won't really show anything until Refactor context menu is opened or Cmd/Ctrl-1 is pressed on the text. I guess you meant a diagnostic with a quick fix (quick fix is a code action).
I propose a diagnostic with Hint severity with a CodeAction being the quick fix for it. When the diagnsotic is off, i.e. set to IGNORE it would act as a regular CodeAction described above.
(FYI: I'm not showing CodeLens for a method annotated with @Query or @NativeQuery)

[martinlippert]

(FYI: I'm not showing CodeLens for a method annotated with @Query or @NativeQuery)

-> #1546

[martinlippert]

@martinlippert I think you meant diagnostic with a quick fix... Code Action don't show up as squigglies under the text... VSCode would show a lightbulb if the cursor is on the text in question and Eclipse won't really show anything until Refactor context menu is opened or Cmd/Ctrl-1 is pressed on the text. I guess you meant a diagnostic with a quick fix (quick fix is a code action). I propose a diagnostic with Hint severity with a CodeAction being the quick fix for it. When the diagnsotic is off, i.e. set to IGNORE it would act as a regular CodeAction described above.

I actually thought about something like this:

where there is an additional code lens showing up behind the code lens showing the SQL statement, showing up with turn into @Query annotation and clicking on that code lens executes the change.

I don't really like to turn this into a validation with squiggly lines, since having no query annotation is the "good, normal" state, what people actually should do when using Spring Data JPA. Therefore, flagging anything like this with a validation and having a validation for this in the preferences makes not a lot of sense to me. Offering a simple code action, where the light bulb appears on the side when the cursor is on the query method, seems like a much better fit to me. And in Eclipse, this appears on the context menu only (and not in the editor) is fine as well - if we have the additional clickable code lens, as described above.

[BoykoAlex]

Fixed via 1fa315f
CodeAction in Eclipse will show up after eclipse-lsp4e/lsp4e#1256 is merged

[martinlippert]

Sounds great. Just as a side note: even though the PR got already merged into LSP4E, due to a major and long lasting outage at the Eclipse Foundation infrastructure, it might take a longer while before we will see new LSP4E snapshot builds coming up.

[BoykoAlex]

@martinlippert oops... just realized now that you wanted to have a separate CodeLens for converting into query annotation... Currently the query code lense has a command associated with it that turns it into the query... It is easy to adjust of course but maybe what I've done is actually okay.... If the query string is long the second CodeLens won't be visible... Long CodeLens is broken up by the ellipsis...

[martinlippert]

I actually like the code lens for converting the it into the annotation to be very explicit. I tried the "click on the query statement codelens to convert it" implementation today and it might be quite confusing and surprising for the user that this is actually possible and what will happen when the user clicks on it.

The user might expect the statement to be executed on the database configured in the tools somewhere else (to see what this query on the database would return - which would be a nice additional feature, btw).

Therefore, I very much like those "actions" to be very clear on the UI, like "convert into @query annotation", or "execute on database XYZ", or whatever... :-)