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#
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.
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.
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.
See #2018.
A String.format token was missing, so `mappingFileName` was printed instead of a `persistenceUnitName`, and `persistenceUnitName` wasn't actually printed at all.
See #2526.
Mark Paluch
Spring Builds
Greg L. Turnquist
Chris Fraser
Christoph Strobl
Diego Krupitza
Conor McGale
Jens Schauder
Cedomir Igaly
John Blum
evgeny.bovykin
Darin Manica
Bajohr, Rayk