Query builders refactoring / rewrite #2973
Conversation
|
There was a problem hiding this comment.
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
| * @since 3.9.0 | ||
| */ | ||
| @Internal | ||
| public final class CosmosSqlQueryBuilder2 extends SqlQueryBuilder2 { |
There was a problem hiding this comment.
I would rename this hierarchy LegacySqlQueryBuilder, adding the number 2 is confusing IMO
There was a problem hiding this comment.
In that case it would be CosmosSqlQueryBuilderNext
There was a problem hiding this comment.
But that's only a temporary name till v5
What do you mean by multiple dialects? SQL query builder can be instantiated with a different dialect, which can come from the annotation metadata |
|
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 |
|
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. |
Rewrite of
QueryBuilderto 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,SqlQueryBuilder2internally.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.