Query builders refactoring / rewrite

[dstepanov]

Rewrite of QueryBuilder to eliminate the conversion to the old criteria model; this will allow us to make modifications to the query builder much faster, allowing us to add more features like functions, etc.

Previous query builders were kept unmodified and replaced with QueryBuilder2, SqlQueryBuilder2 internally.

There are some small changes in how queries are generated. (IN literal values are now generated already expanded instead of doing it at the runtime).

In Micronaut 5 v2 implementation will replace the old builders.

[sonarcloud[bot]]

Quality Gate failed

Failed conditions
31.1% Duplication on New Code (required ≤ 10%)
4 New Bugs (required ≤ 0)
40 New Critical Issues (required ≤ 0)
1 New Blocker Issues (required ≤ 0)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[dstepanov]

Overall seems fine, but if we are going to rewrite this hierarchy I would like to see a model where we can support multiple dialects instead of just one like we have today.

It would also be nice if the dialect could be configured at the annotation processor argument level

What do you mean by multiple dialects? SQL query builder can be instantiated with a different dialect, which can come from the annotation metadata

[graemerocher]

What I would like is:

tasks.withType(JavaCompile).configureEach {
    options.compilerArgs.add("-Amicronaut.data.dialects=ORACLE,H2")
}

@JdbcRepository // no dialect
interface BookRepository extend CrudRepository<Book, Long> {}

datasources.default.dialect=H2 # use h2

@Inject BookRepository bookRepository; // receive H2 repository

[dstepanov]

I don't see a big problem with supporting it. We would need to execute the query builder a few times and store multiple results.