Added integration tests in org.springframework.data.jpa.infrastructure that will not be included in the normal test execution as they are purely means to quickly identify potential differences in persistence provider implementations.
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.
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.
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
The repositories can now be bootstrapped using @EnableJpaRepositories annotation as follows:
@Configuration
@EnableJpaRepositories
class ApplicationConfig {
// … declare EntityManagerFactory
// … declare PlatformTransactionManager
}
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.
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.
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.
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.
SimpleJpaRepository now deletes entities 1 by 1 for a call to deleteAll() to ensure the cascades get triggered. Introduced deleteAllInBatch() that contains the old behaviour.
Extracted the DateTime instance calculation to be used for auditing into a DateTimeProvider callback interface to open it up for customization. AuditingEntityListener can get an instance of it configured. Exposed the property via the auditing namespace. By default a CurrentDateTimeProvider its used that contains the behavior we had so far.
Introduced to support @IdClass to define entity ids. The JpeMetamodelEntityInformation builds instances of the annotated @IdClass in case any of the attributes of the entity declared in the @IdClass has a non-null value.
We will now prefer a declared NamedQuery for count queries instead of deriving it from the actual NamedQuery under the following conditions:
- by default a query named ${namedQueryName}.count exists
- the name of the NamedQuery to be used is defined in @Query(countQueryName = "…")
Note that a potential reconfiguration of the NamedQuery name will be taken into account for the according count query name to assure symmetry. Examples
Page<User> findByLastname(String lastname, Pageable pageable)
NamedQuery name: User.findByLastname
Count NamedQuery name: User.findByLastname.count
@Query(name = "Foo.bar")
Page<User> findByLastname(String lastname, Pageable pageable)
NamedQuery name: Foo.bar
Count NamedQuery name: Foo.bar.count
@Query(countName = "Foo.bar.count")
Page<User> findByLastname(String lastname, Pageable pageable)
NamedQuery name: User.findByLastname
Count NamedQuery name: Foo.bar.count
@Query(name = "Foo.bar", countName = "something")
Page<User> findByLastname(String lastname, Pageable pageable)
NamedQuery name: Foo.bar
Count NamedQuery name: something
Override isPersistenceUnitOverrideAllowed() newly introduced in Spring 3.1.1 to indicate we can deal with persistence units of the same name. For Spring 3.0.x versions the implementation was not broken.
We now call Metamodel.managedClass(…) instead of Metamodel.entityType(…) to be able to detect ids in @MappedSuperclass types as well. Unfortunately this currently still fails with Hibernate as theit Metamodel implementation only considers entities. See [0] for further details.
[0] https://hibernate.onjira.com/browse/HHH-6896
Moved @PersistenceContext annotation to the setter method to make it overridable and thus re-configurable. Introduced protected getEntityManager() method to allow subclasses having access to the EntityManager.
Repository query methods can now be equipped with a @Lock annotation that carries the LockModeType to be used when executing the query. Beyond that, CRUD methods can be redeclared to carry lock metadata as well.
interface UserRepository extends Repository<User, Long> {
// CRUD method redeclaration
@Lock(LockModeType.READ)
List<User> findAll();
// Query method
@Lock(LockModeType.READ)
List<User> findByLastname(String lastname);
}
For pagination we already need to trigger a count query to find out the total number of pages available. Now if there are less elements available than the offset of the current page points to we don't need to trigger the actual content reading query at all. E.g. if there's only 20 elements in the database and we request page 3 by a page size of 10 we already know that there won't be any elements found.
Implemented that optimization for general CRUD pagination as well as pagination in query methods.
Query derivation mechanism now supports True and False as keywords in finder methods:
class User {
boolean active;
}
interface UserRepository<User, Long> {
List<User> findByActiveTrue() ;
}
Added ClasspathScanningPersistenceUnitPostProcessor that will scan the configured base package for classes annotated with @Entity or @MappedSuperclass and add them to the PersistenceUnit handled.
Beyond that it will scan for JPA XML mapping files if an optional mapping file name pattern is configured on the PUPP instance.
@Query now has a name attribute that allows defining the NamedQuery name to be used to override the convention based ${domainClass}.${finderMethodName}.
@Query can now be used to execute native queries by setting the nativeQuery flag of the annotation to true. Polished JavaDoc of the @Query annotation. Upgraded EclipseLink dependency to 2.3.1 as we stumble over a NullPointerException otherwise which is fixed in the current one.
