We now build a correct count query for entities that use a compound key mapped using @IdClass. Added integration tests for EclipseLink and OpenJPA to run the basic tests of SimpleJpaRepository against different persistence providers. Ignored failing test against OpenJPA.
When applying sorting options to a Specification based query we have to make sure to apply left joins where necessary as we otherwise exclude results with null associations. Applying the sort options does an enhanced inspection of the target path and declares a left join instead of a get if the path logically points to an entity. The Metamodel API is not without caveats here, see http://bit.ly/10geC02.
The execution of a count query can potentially return multiple values instead of just a single one. This causes persistence providers to throw an exception as we trigger ….getSingleResult() in SimpleJpaRepository. We're now calling …getResultList() and sum up all values returned.
Specifications.not(…) now also gets applied correctly when used without where(…) wrapper. Polished Specifications class, JavaDoc and added not null assertions.
If a manually defined query uses outer joins, prefixing the sort criteria handed to the execution of the method causes an additional join being added as the JPA considers path expressions to be inner joins always (see Sect. 4.4.4, JPA 2.0 spec).
We now parse the outer join aliases potentially used in a manually defined JPQL query and do not prefix the query with the root entity's alias.
JpaClasUtils.isEntityManagerOfType(…) now uses the given EntityManager's ClassLoader to try to load the given concrete classname. We're actually using the EntityManager's delegate here which is usually some provider specific implementation (e.g. a Hibernate Session). This assumes that the ClassLoader who initially loaded the class to create the delegate instance will also see the special EntityManager interface.
We bound the given Iterable<ID> using List as parameter type which gets rejected if you hand in something that's not a List actually (e.g. HashSet). Changed parameter binding to hand in Iterable now.
We now expect a much broader range of exceptions possibly popping up from EntityManager.createQuery(…). It turns out the spec is not very strict about what must be returned from the call in case the provided query String is invalid. E.g. Hibernate seems to throw an IllegalStateException in case the query seems generally acceptable but has a typo in some keyword.
We now catch RuntimeException invoking the call and simply rethrow the original exception if it is an IllegalArgumentException indeed but wrap any other into an IAE.
See http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2012-07/message/17
Introduced Querydsl helper class to allow using more functionality from QuerydslJpaRepository as well as QuerydslRepositorySupport. Moved applyPagination(…) and applySorting(…) methods into that helper class. Removed QuerydslUtils and moved functionality into Querydsl helper.
This change breaks exposed API in Querydsl repo and repo support classes.
Added brief section on how to use the CDI extension. Poslished documentation in general: updated copyright year, removed revision history, fixed links to Maven repositories, added missing section ids to create stable links, improved CSS for HTML rendering, improved PDF rendering.
Drop custom method to determine whether a query method returns an entity and rather use the newly introduced method in Spring Data Commons' QueryMethod.
Reactivated test cases that were not executed because they were named *Test, not *Tests. Upgraded to Maven Surefire Plugin 2.12 and activated parallel test execution per method. Upgraded Maven Compiler Plugin to 2.4.
When executing a projecting query through a native query we must not use em.createNativeQuery(String, Class<?>) as this expects an entity type as type parameter. We now use the newly introduced isQueryMethodForEntity() on JpaQueryMethod to determine whether the query is actually projecting and rather use the plain em.createNativeQuery(String).
Fixed dependency configuration for Hamcrest and JUnit (upgrade to JUnit 4.10, depending on junit-dep).
The optimization for DATAJPA-124 introduced a NullPointerException being thrown if the Pageable instance handed to a paging query was null. Added a guard to handle this situation correctly. Unfortunately had to disable the test case for EclipseLink as the bug with HSQL still exists.
We now do an exists check inside SimpleJpaRepository.delete(ID id) before actually triggering the deletion to avoid an exception when trying to delete a null value. We throw an EmptyResultDataAccessException to indicate the nonexistent entity now.
Change log level for one of the log messages in NamedQuery from INFO to WARN. This was done to provide more forceful information to the developer that sorting applied with named queries will be ignored.
MergingPersistenceUnitManager now also merges mapping file locations. We also make sure now that the persistence unit root URL does not get added twice accidentally as some persistence providers refuse to work then.
The query derivation mechanism now supports StartingWith, EndingWith and Containing as keywords using the Criteria API's like predicate and massaging the given parameters accordingly. Refactored parameter binding for CriteriaQuery instances to encapsulate the knowledge of how to massage a parameter based on the type.
To avoid the query execution to fail due to typos in the named parameter mapping, JpaQueryMethod now checks the named parameters potentially annotated using @Param to be present in the annotated query.
Upgraded to Querydsl 2.3.3. We now choose the appropriate JPQLTemplate depending on the used persistence provider inside QueryDslRepositorySupport as well as QueryDslJpaRepository.
When using a projection to a collection property in a manually defined query we must not set the domain class type when creating the query:
interface UserRepository implements Repository<User, Long> {
@Query("select u.colleagues from User u where u = ?1")
List<User> findColleguesFor(User user);
}
We now must not call em.createQuery(queryString, User.class) as we were before as this causes some persistence providers (tested with Hibernate) to reject the query type. Thus we now simply create an untyped query as we don't need the typing here. Unfortunately we cannot activate the test case currently as OpenJPA does not support using projections on a collection property and breaks the bootstrap process of the integration test.
Oliver Gierke
Thomas Darimont
Oliver Gierke
manish-in-java