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.
In order to correctly identify aliases in the order by clause, we cannot process the from clauses left-to-right using regular expressions. These must be removed inner-to-outer. Commit c93aa25 resulted in a bug where the subquery would be incorrectly identified as the alias, as by the following query:
```
from Parent p join p.children c where not c.id not in (select c2.id from Child c2)
```
Passing in a Sort.by("name") would result in "order by c2.name" instead of "order by p.name". Thus, it was using the alias of the inner query instead of the outer query. [This comment](https://github.com/spring-projects/spring-data-jpa/issues/2260#issuecomment-929510358) suggests removing the content of the inner query, with the caveat of the entire query being surrounded by parenthesis. This commit does exactly that, by removing the subquery before the alias is identified. It also handles the case when the entire query is surrounded by parenthesis. Unit tests illustrate this along with several examples of removing the subquery to correctly identify the alias for the order by clause.
See #2260 (c93aa25), #2500, #2518.
In commit 3e64d9ad9b a bug got introduced that uses the next symbol after the table name for the count function. With this commit this should be now resolved. The count query will use `*` when there is no alias present nor a variable.
Related tickets #2341, #2177, #2260, #2511
JpaRepository accepts Iterable<ID> for bulk deletes. But some JPA providers require Collection<ID> instead. To avoid breaking any APIs, convert the incoming argument if it's not already a Collection.
See #2242.
In several ways, it's possible to have various ORDER BY clauses, including SQL OVER (windowing) clauses. Need to improve handling of ORDER BY.
See #2260.
The `COUNT_MATCH` does not consider line breaks after the `from` clause or the `where` clause. This leads to a no match scenario in the construction of the count query. With the fix we now consider line breaks/whitespaces after the `from` and `where` clause.
See #2341
Related tickets: #2177
A few test that used reflection to access the actual SQL executed by a Query object failed with `java.lang.reflect.InaccessibleObjectException: Unable to make field protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h accessible: module java.base does not "opens java.lang.reflect" to unnamed module @1b9e1916`.
This change replaces the reflection used by a proper call to `unwrap`.
Original pull request #2231
Hibernate 5.4.22 started including types managed by custom user types in the embeddables exposed via JPA's Metamodel API. This causes those to be considered types to explicitly map (read: unfold) in Spring Data REST. We now exposed a cleaned up view on this via a tweak in JpaPersistentPropertyImpl (ultimately in JpaMetamodel) looking for @Embeddable annotation on types allegedly considered embeddable by Hibernate.
Fixes#2421.
We now use IdentifiableType.hasSingleIdAttribute() to detect whether a type should have an IdClass. hasSingleIdAttribute is defined to return false if an IdClass is being used. It could also return false in case multiple identifier attributes are in place (composite Id) which is a bit of a grey area. At least we avoid using Hibernate-specific API.
Original pull request #2412
See #2330Closes#2391
