Null values are wrapped with a special handler when interacting with Hibernate. However, this becomes an issue for queries when LIKE or CONTAINS are applied. In this situation, the null needs to be condensed into an empty string and any wildcards can then be applied with expected results.
Closes#2548, #2570.
Supercedes: #2585.
Related: #2461, #2544#
As recommended in [0], we now set up our integration tests verifying the application of entity load graphs using a lazy @ManyToOne relationship.
[0] https://hibernate.atlassian.net/browse/HHH-15391
Related to #2423.
TypedQuery inspection through its String representations seems to be a bit flaky in Hibernate 6 still [0]. Tweaked the code to extract a query string from a query object to try the new way first but fall back to the old way, as this seems to work under some conditions, too. Adapted the test case in which we could rather inspect the new SqmQuery API for test result verification.
Re-bootstrapping the EntityManagerFactory for the same persistence unit causes the second bootstrap to fail als apparently foreign key names are randomized and the second bootstrap doesn't create a new constraint but tries to work with a new name. Tweaked the offending test case to reuse the existing EMF declaration as it actually only tests the qualified wiring into clients.
Applying an entity graph is causing a StackOverflow in current Hibernate 6. Filed an issue [1] and disabled the test case for now.
Dial back on the flip to use String as parameter type for like expression escape characters as Eclipselink rejects that. The JPA spec chapter 4.2.10 allows both Character and String to be used. Filed [2] with Hibernate to ask for reintroduction of the support for characters and commented out the test cases for now.
Deprecated CustomHsqlHibernateJpaVendorAdapter as it's not needed on Hibernate 6 anymore. Rewrote HibernateJpaParametersParameterAccessor to use Hibernate 6 API.
Add Hibernate 6 upgrade information to the reference docs.
Related ticket: #2423.
[0] https://hibernate.atlassian.net/browse/HHH-15389
[1] https://hibernate.atlassian.net/browse/HHH-15391
[2] https://hibernate.atlassian.net/browse/HHH-15392
For count queries always start with Long instead of the domain type (Hibernate 6 rejects a mismatch between the type the query was originally set up for and the type to be actually selected).
For delete queries, do not use the type to be read, but the domain type as we load the individual instances first to make sure we properly fire entity callbacks.
Related ticket: #2423.
We now use the AOT infrastructure of Spring Framework 6 and data commons to provide AOT support building the foundation for native image compilation.
Additionally we register hints for GraalVM native image.
Also update jpa auditing configuration to avoid inner bean definitions.
See: #2497
Original Pull Request: #2588
We now support `ValuesStatement` and `SetOperationList`. This allows native queries to use `union`, `except`, and `with` statements in native SQL queries.
Closes#2578.
This implementation of QueryEnhancer was originally designed for SELECT statements. This commit now handles DELETE and UPDATE operations by side-stepping any sorting or other changes.
Keep in mind that "enhancing" non selects does not have any effect on them (and the current default implementation `QueryUtils` does not care either aka it often just returns the same query, null or empty string).
Closes#2555
The checks for JDBC and JPA parameters were sloppy and based on side effects. By using zero width lookaheads, we can precisely spot situtations where the user has both types of parameters. Otherwise, let the query on through to the JPA provider.
Closes#2551.
This does integration testing with both EclipseLink and Hibernate, verifying that queries are run properly. I also inspected the generated queries in the debugger, verifying the "where true=1" was no longer generated.
Closes#2282.
By properly parsing "order by" clauses, Spring Data JPA can apply sorting parameters to the end of queries in the event of complex queries that involve nested subselects.
Closes ##2496, #2522, #2537, #2045.
Instead of relying on the JPA provider to handle page offsets exceeding Integer.MAX_VALUE, do the check inside Spring Data JPA and provide a more meaningful error message.
Closes#2502.
By using exceptions for flow control, other critical exceptions are getting masked. The lack of a resolvable query should instead leverage some sort of null value object.
Closes#2018.
We now guard against null values returned from ParameterExpression.getJavaType() before inspecting the value further as it turns out that Class.isAssignableFrom(…) chokes on null values being passed.
Looks like Hibernate six returns null in scenarios it previously didn't.
Spring Data Commons patched handling subclasses of special parameter types through spring-projects/spring-data-commons#2626. This commit adds test cases ensuring things work properly with Spring Data JPA.
See #2013.
A String.format token was missing, so `mappingFileName` was printed instead of a `persistenceUnitName`, and `persistenceUnitName` wasn't actually printed at all.
See #2526.
When performing a count operation, we are using countDistinct from JPA, and hence, don't need the JpaQueryCreator applying distinct outside the whole thing.
Also added some details in the ref docs to help guide users on writing proper distinct-based queries.
See #1380.
