In case the AuditingEntityListener is declared globally and <jpa:auditing /> is not activated the listener is considered by the JPA infrastructure but not configured correctly. In particular no AuditingHandler gets injected which leads to NullPointerExceptions every time an entity is persisted. Added checks for null to the access and skip it if no AuditingHandler is present.
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.
Upgraded to use new methods introduced for DATACMNS-269 to be able to detect mapping annotations independently of whether they are declared on the field or an accessor method for the property. Upgraded to new artifactId Spring Data Commons is distributed under.
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.
We move away from Maven version ranges as they complicate the build and dependency resolution process. They make the build in-reproducible. Users stuck with a 3.0.x version of Spring will now have to manually declare Spring dependencies in their needed 3.0.x version. Not that at least Spring 3.0.7 is required currently.
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
The repositories can now be bootstrapped using @EnableJpaRepositories annotation as follows:
@Configuration
@EnableJpaRepositories
class ApplicationConfig {
// … declare EntityManagerFactory
// … declare PlatformTransactionManager
}
