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.
Added guard against null values in identifiers. Null values can occur because id generation was not completed yet. Add tests for identifier derivation using @IdClass for Hibernate, OpenJPA and EclipseLink.
Original pull request: #133.
We execute paged queries now in an optimized way. The data is obtained for each paged execution but the count query is deferred. We determine the total from the pageable and the results in which we don't hit the page size bounds (i.e. results are less than a full page without offset or results are greater 0 and less than a full page with offset). In all other cases we issue an additional count query.
Extracted the functionality to check for JPA managed types into a dedicated wrapper for the JPA Metamodel. This allows all clients to benefit from the null guards we have to put in place due to [0]. Adapted the fix introduced for DATAJPA-904 to make use of the newly created infrastructure, too.
[0] https://hibernate.atlassian.net/browse/HHH-10968
We now inspect QueryByExamplePredicateBuilder.isAndMatching() to decide whether to concatenate the predicates built using and or or.
Related tickets: DATACMNS-879.
Some persistence providers (Hibernate *cough*) return null for a ManagedType's JavaType, which we perviously didn't expect in the implementation of JpaPersistentPropertyImpl.isEntity().
We now eagerly extract all managed types from the Metamodel and gracefully skip nulls so that we don't have to look up the types repeatedly.
We now check manually defined queries for whether the projection is equal to the used alias and don't use a Tuple query in this case. This allows the manually defined queries to still define the projections manually but also the returned objects be wrapped with projection interfaces easily.
We now use a completely reflective lookup of the Hibernate query string as well as for the Hibernate specific PersistenceProvider lookup in tests.
Added build profile for Hibernate 5.2 but it's currently not working due to Hibernate complaining about an invalid identifier mapping on CustomAbstractPersistable which is overriding the parent types property on accessor working fine on 5.1.
The build profile for 5.1 is still broken due to the fixed but yet unreleased HHH-10514 [0] and the not yet fixed HHH-10515 [1] (apparently fixed but still open and unreleased) which has been broken since 5.0.8.
[0] https://hibernate.atlassian.net/browse/HHH-10514
[1] https://hibernate.atlassian.net/browse/HHH-10515
Count queries that are executed in the context of paginated queries using Specifications now get their order specifications removed as they get rejected by some databases.
We now explicitly check the return types for queries using manually defined queries to find out whether it's a JPA managed type in the first place. Only if that's not the case we resort to a Tuple query and assume DTO mapping happening downstream.
This is necessary as a singular projection expression in the query might simply return an element of the aggregate and thus doesn't need any DTO creation. In case an unmanaged type is returned from the query method we assume DTO creation.
We convert a given Example to a set of and combined Predicates using CriteriaBuilder. Cycles within associations are not allowed and result in an InvalidDataAccessApiUsageException. At this time only SingularAttributes are taken into concern. Switched to types used in DATACMNS-810.
Related tickets: DATACMNS-810.
Original pull request: #164.
Added prototypic support for query by example queries to
SimpleJpaRepositories. Clients can use an Example object to
wrap an existing prototype entity instance that will be used to
derive a query from.
Related tickets: DATACMNS-810.
Original pull request: #164.
We allow and support composing annotations for: @Entity, @EntityGraph, @Lock, @Modifying, @Query, @QueryHints as well as @Procedure.
Original pull request: #166.
We now don't assume an expectedType property configured for every declaration of <jee:jndi-lookup /> but rather skip elements that don't have the attribute configured.
The lookup of EntityManagerFactory bean definition now also detects JndiObjectFactoryBean instances that have the expected type configured to EntityManagerFactory.
Related ticket: DATACMNS-821.
Previously we triggered a tuple query execution even if a query was manually defined and contained a constructor expression (e.g. new Dto(a.foo, a.bar)). We now explicitly detect that case and simply execute the query as is.
Previously the first property was checked for being a collection to trigger collection contains handling. This is wrong for nested property traversals as they might end up in a String for which a like binding has to be applied then.
We're now inspecting the leaf property for being a collection to trigger that special binding.
To prevent multiple attempts of class loading down stream for multiple lookup calls to fromEntityManager(…) or fromMetamodel(…). We now avoid the repeated lookups of a PersistenceProvider instance by reusing a canonical one created in CreateQueryLookupStrategy.
Instead of looking up the PersistenceProvider for every entity again, we now look it up once in the JpaMappingContext for reuse on all JpaPersistentEntity instances.
Original pull request: #161.
CrudMethodMetadata exposed by the CrudMethodMetadataPostProcessor previously used an AbstractLazyCreationTargetSource to lookup the thread-bound instance. That instance however is cached and never released so that all subsequent calls to it returned the same (and in most cases wrong) instance.
We're now implementing TargetSource directly to make sure we obtain a fresh instance on every access of the CrudMethodMetadata proxy.
Based on the work for DATACMNS-89 we now use the metadata exposed by ResourceProcessor to optimize queries that are to be projected on the query execution level.
If a projection interface is used that's not using any dynamic expression, we now explicitly query for a JPA Tuple consisting of all properties required for the projection interface. The same applies to DTOs that use an @PersistenceConstructor.
Related tickets: DATACMNS-89.
The if a collection expression is concluded with a Contains keyword, we now translate that into a "member of"-expression on the criteria query. This allows to check whether a collection property contains a singular value.
List<User> findByRolesContaining(Role role);
This will return all users that have the given role.
Tweaked the lookup of a version property on a mapped superclass. Hibernate doesn't expose itself as being very supportive in that: on versions below 4.3 the method primarily intended to look it up (IdentifiableType.getVersion(…)) expects you to hand in exactly the type of the property you're trying to find in the first place. Awesome, not.
If this fails, we now explicitly traverse the singular attributes and recursively traverse super types. Unfortunately, on the Hibernate version broken as defined above, the check for attribute.isVersion() fails even for the version property as the implementation holds all singular attributes with one for the version property which is not marked as such.
tl;dr; - everyone trying to use @Version on a mapped superclass and a primitive identifier in an entity on Hibernate 4.3 will still have to implement Persistable to make sure EntityManager.persist(…) is used for new entities.
The thread-local proxy for the CrudMethodMetadata is now created using the bean ClassLoader, which the repository factory gets set from the container.
Renamed the property for the post processor and its lookup method.
The application of sort expressions is guarded by the detection of join aliases to potentially prefix the sort expression with the default alias. In case a raw property reference to sort by started with a join alias the property name wasn't prefixed. We now explicitly check for a start with the alias followed by a dot.
We now use a ParameterAccessor to obtain query method parameters in ParameterBinder to benefit from value post-processing (e.g. unwrapping of Optional etc.).
Related tickets: DATACMNS-768.
