StreamExecution now makes use of the newly introduced SurroundingTransactionDetectingMethodInterceptor to find out about whether the transaction is used in code that already has a transaction running. This is necessary to make sure the Stream returned by the method can actually be consumed as the surrounding transaction keeps the transaction open.
Related tickets: DATACMNS-959.
We now also return a single-element tuple value as is if it's null as for some reason some persistence providers (*cough* Hibernate *cough*) will return a single-element, null value containing tuple (instead of null in the first place) for queries that didn't yield a result.
Improved our detection of Hibernate 5.2 in the query lookup for String based queries, general PersistenceProvider detection (due to changed interface hierarchies in Hibernate 5.2). Tweaked the setup for some integration tests to point to Hibernate 5.2 specific persistence units using the new location for the persistence provider implementation class.
Looks like the test case introduced for DATAJPA-622 introduced an invalid identifier setup which isn't tolerated on Hibernate 5 anymore. Simplified that to keep using Long identifiers to avoid the redeclaration of getId() which caused the mapping issue.
Upgraded minimum Hibernate required version to 4.3. Removed Travis build profiles for everything below that. Upgraded to Spring Framework 5.0 snapshots.
Removed integration test execution for OpenJPA for now as Spring Framework 5 doesn't ship OpenJpaVendorAdapter anymore as there's no JPA 2.1 compatible OpenJPA version available currently.
We now support exists projections in derived queries. Queries select the primary key using tuple queries limiting the result to the first row.
interface UserRepository extends Repository<User, Long> {
boolean existsByFirstname(String firstname);
}
Original pull request: #176.
Upgraded to Spring Data build parent and Commons in 2.0. No upgrade to Spring 5 yet as it requires Hibernate 5 which currently breaks our tests, mostly because of [0].
Added workaround for compiler ambiguities that stem from the upgrade to 1.8 as compile target [1]. Temporarily removed tests for JpaSort for the same reason.
Adapted to API changes in DefaultResourceLoader in preparation of the move to Spring 5.
[0] https://hibernate.atlassian.net/browse/HHH-10690
[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010521.html
Previously EntityManagerFactory was created manually which resulted in LocalContainerEntityManagerFactoryBean not being exposed to
ApplicationContext. The latter is an important bean since it enables
exception translation.
Original pull request: #180.
We now create the count query that's required for pagination queries without applying the query hints.
Related tickets: DATAJPA-684
Original pull request: #182.
If a query returns a one-element tuple and that single element returned is type-compatible to the type to be returned we return it as is. Previously, we insisted on creating a Map from the tuple (which usually works for projection interfaces).
This is needed to support custom simple types (i.e. types that the JPA provider can convert itself but which are not exposed through the metamodel - usually types managed through JPA AttributeConverters or provider specific conversion mechanisms).
When creating the selections for a derived query using a projection we now explicitly create joins for plural attributes. Looks like Hibernate fails to create a proper query if the path is referred to via root.get(…) and the select clause includes references to other non-plural attributes.
We now decline sort expressions that contain functions such as ORDER BY LENGTH(name) when used with repository having a String query defined via the @Query annotation.
Think of a query method as follows:
@Query("select p from Person p where LOWER(p.lastname) = LOWER(:lastname)")
List<Person> findByLastname(@Param("lastname") String lastname, Sort sort);
Calls to findByLastname("lannister", new Sort("LENGTH(firstname)")) from now on throw an Exception indicating function calls are not allowed within the _ORDER BY_ clause. However you still can use JpaSort.unsafe("LENGTH(firstname)") to restore the behavior.
Kudos to Niklas Särökaari, Joona Immonen, Arto Santala, Antti Virtanen, Michael Holopainen and Antti Ahola who brought this to our attention.
We're now more lenient against manually defined queries that do not contain aliases when adding order by clauses to them. The alias detection now doesn't accidentally pick up "where" anymore in case no primary alias is declared and the code applying the order by clause only qualifies the expressions created if there actually is an alias in the first place.
We now exclude all candidates beans that could theoretically become an EntityManagerFactory unless we definitely know so.
Previously bean definitions for JndiObjectFactoryBean that didn't expose an expected type (e.g. ones defined via JavaConfig) were propagated to the creation of a DefaultJpaContext.
JpaQueryExecution applies a ConversionService to convert between low-level types such as integers, longs and byte arrays. That ConversionService also preemptively converts objects into JDK 8's Optional in case the invoked method's return type is Optional.
We now explicitly remove the converter taking care of the latter to avoid Optionals to be created before the actual result conversion is applied, as it needs to see the raw value to create DTOs or interface based projections correctly.
Use a page size of 1 to enforce a count query creation. The expected exception is only visible with Hibernate 4.1.x when a count query is issued.
Related pull request: #174.
Slightly loosened our regular expression to detect constructor expressions as previously it didn't match select expressions that contained a distinct clause.
