[aot repositories] use text block when converting spring data jdbc query strings

[martinlippert]

When converting generated queries for Spring Data JDBC repositories, the query can contain a lot of strings in quotes (and therefore escaped quote characters). A better way of writing those queries is to put them into a text block, which then avoid having to escape the quotes.

[catturtle123]

Hi @BoykoAlex,

I noticed this issue is currently assigned to you for the 5.1.0.RELEASE milestone.

Could you let me know if you have already started working on this? If not, would it be okay for me to pick this up and submit a PR?

If I may contribute, here is my proposed approach:

1. Implementation Plan
I plan to modify DataRepositoryAotMetadataCodeLensProvider.

• I will introduce logic to check if the query string contains quotes.
• If it does, the generator will switch to using Java Text Blocks (""") to avoid excessive escaping.
• If not, it will fall back to the existing standard string behavior.

2. Testing Plan
I plan to add a new test case to DataRepositoryAotMetadataCodeLensProviderJdbcTest.

• This will verify that the generated @Query annotation correctly uses the text block syntax and preserves the raw SQL structure.

Please feel free to let me know if I can pick this up and if the proposed direction looks good to you.

[BoykoAlex]

@catturtle123 please go ahead since I haven't started this at all. Thanks very much! I guess only 2 additional things came to my mind:

1. I'd have this logic for all repositories not just jdbc (don't see a reason why not)
2. I'd check what the java version on the project. if 15 or above then text blocks otherwise the current single line string. The IJavaProject should have info about the java version.

[catturtle123]

That sounds good to me.

Originally, since the issue was raised in the context of JDBC, I was thinking of keeping the change minimal and scoped just to JDBC repositories.
But I agree there’s no strong reason to limit it, and applying this to all repository types makes sense and keeps the behavior consistent.

Regarding the Java version, I agree with this approach and will follow it when deciding whether to use text blocks.

I’ll rely on the Java version information from IJavaProject and reflect this logic in the implementation and accompanying tests when preparing the PR.

[catturtle123]

I've submitted a PR to address this issue.

PR: #1762

[martinlippert]

Thanks a lot @catturtle123 for jumping on this and working on a PR. That is awesome.

So, looks like the first step here is done and @BoykoAlex merged the PR #1762. Now, I think we need to go one step further... :-)

Now the query param is using a text block, but the result is missing important things:

• the indentation of the text block is not correct
• the content of the text block is always a single line (which makes using a text block more or less useless)

Instead of turning this into a single line text block, the text block should be split into multiple lines. The line break should be done at keyword boundaries, so that instead of generating:

    @Query("SELECT u FROM users u WHERE u.username = :username")

the code lens action should generate:

    @Query("""
            SELECT u FROM users u
            WHERE u.username = :username
            """)

Ideally the decision whether to turn this into a single line query or a multiline text block query should also get a preference setting, so that users can decide which style they prefer.

[BoykoAlex]

@catturtle123 Splitting the query properly on multiple lines needs a bit of investigation work. You'd need to find the proper parser for the query and split it somehow around parser tree nodes, i.e. "select" clause one line, "where" clause second line and so on. Probably for each query type you'd have a "formatter" class which would share common interface. Give formatter a string query, the formatter uinder the hood parser the query and splits it over multiple lines a line per clause... Anyway, this would my rough idea for it.

[catturtle123]

@martinlippert and @BoykoAlex, thank you for the great feedback!

Regarding the design, I'm planning to handle this via a global preference in the user settings so users can toggle their preferred query style.

As suggested by Alex, I'll introduce a common formatting interface and create separate implementation classes for each specific query type to keep the logic modular and extensible. For JPQL and SQL specifically, I’ve encapsulated the formatting logic using the existing JpqlLexer inside a dedicated JpqlQueryFormatter class.

Also, do you have a preference for the default style? Should it stay as the standard single-line string to maintain current behavior, or would you prefer the new multiline text block to be the default?

Does this design and the use of the lexer sound like the right direction to you?