This commit makes sure to avoid unnecessary parsing of queries when sorting must not be appended.
Additionally the parsed result is cached on a per query string with sort expression basis to avoid parsing repeating occurrences of the same expressions eg. while paging through results.
Closes: #3310
Original pull request: #3321
This change allows to use collection/array arguments with scalar operators when targeting a collection like property.
Closes#3356
Original pull request: #3359
This commit makes sure we create individual parameter bindings for the count query instead of reusing the bindings from the actual query. This ensures we do not miss bindings that are present only in the count query.
Closes: #3293
Original pull request: #3339
This commit makes sure to retain signed expressions (hql, eql, jpql) and literals (eql, jpql) when rendering the query.
Prior to the change singed expression/literal rendering added a space between the sign and the actual value so that `-1` would become `- 1` and `-count(u)` would be `- count(u)`.
Additionally a minor glitch in the jpql rendering was resolved that would add an extra space before the closing bracket of a LENGTH expression.
See: #3342
This commit fixes an issue where an extra space is added between the sign and the actual value of signed numerics.
Closes: #3342
Original Pull Request: #3343
Move AspectJ dependency from test into optional. Add annotation processor paths to compiler plugin for discovery by Gradle Enterprise.
Rollback replacer/conditional antlr paths.
See #3282
by separation of concerns: Let
- Maven Compiler do annotation processing without compilation and
- AspectJ Maven compilation of all Java sources and aspects without
annotation processing.
Actually, we could let AJ Maven do all the work, but it would be
difficult to configure everything correctly in JDK 9+, because AJ Maven
is incomplete regarding automatically putting everything on the right
module paths. so, this separation of concerns saves tedious
configuration work.
Relates to https://github.com/mojohaus/aspectj-maven-plugin/issues/15.
See #3282
Aspect-enhanced classes need aspectjrt on the class path. If it is not,
the AspectJ Compiler usually complains, either warning or even
failing the build, also via AspectJ Maven. The aspectjweaver, however,
is for load-time weaving. It is a superset of aspectjrt, but bigger than
necessary. Also, the weaver was only test-scoped, but also during normal
runtime aspectjrt is necessary. Without it, it can only work by the
lucky chance that Spring already depends on aspectjweaver, which is not
good dependency management. Each Maven module should be self-consistent.
Aspectjrt was a plugin dependency for AJ Maven, which is also
superfluous, because aspectjtools already is a superset of
aspectjweaver, i.e. it also contains aspectjrt. Hence, aspectjtools is
all AJ Maven needs, but the compiled application is who really
needs aspectjrt.
See #3282
This commit makes sure to render the entire statement after applying the sort expression via the QueryEnhancer. Previously only parts, the actual statement body, had been considered.
Closes: #3263
Original Pull Request: #3264
Mark Paluch
Christoph Strobl
Stefano Cordio
Shigeru Hagiwara
Eduard Dudar
Pranav
devholic22
Alexander Kriegisch
Mark Paluch
Oliver Drotbohm
Oliver Drotbohm