Simplify PersistenceProvider by removing PresenceDetector interface. Refine presence detection to make present field final. Add warning suppressions as we know that we duplicate code (similar code) and that ANTLR doesn't generate methods with nullable annotations.
See #3170
Original pull request: #3176
Use Hibernate parameter accessor for native queries only to avoid affecting JPQL queries.
Co-locate Hibernate-specific parameters accessor as the same package as JPA parameters accessor.
Remove Parameter Accessor reference from Persistence Provider since it's created in AbstractJpaQuery.
Closes#3137
Original Pull Request: #3173
This change publishes a build scan to ge.spring.io for every local build from an authenticated Spring committer and for CI where appropriate access tokens are available. The build will not fail if publishing fails.
This change also allows the build to benefit from local and remote build caching, providing faster builds for all contributors.
Additionally, the project will have access to all features of Gradle Enterprise such as:
- Dashboards to view all historical build scans, along with performance
trends over time
- Build failure analytics for enhanced investigation and diagnosis of
build failures
- Test failure analytics to better understand trends and causes around
slow, failing, and flaky tests
See #3142
We now inspect individual parameters instead of the resulting query whether the query contains JDBC-style bind markers. Previously, we inspected the final (rewritten) query which might have contained question marks in literals leading to improper validation failures.
Closes#3125
- Switch to io.spring.maven.antora plugins
- Move Antora to spring-data-jpa modulen. Placing in parent folder
means that each module will also have the Antora plugin applied to it
and the antora task will fail on those modules.
See #3094
We now verify all bindings to ensure that a like-parameter doesn't mix up with plain bindings (e.g. firstname = %:myparam or lastname = :myparam). We also create unique synthetic parameters for positional bindings.
Also, fix Regex to properly detect named, anonymous and positional bind markers.
See #3041
We now distinguish between the binding parameter target and its origin. The parameter target represents how the binding is bound to the query, the origin points to where the binding parameter comes from (method invocation argument or an expression).
The revised design removes the assumption that binding parameters must match their indices/names of the method call to introduce synthetic parameters for different binding variants while using the same underlying invocation parameters.
See #3041
