Changed the implementation of SimpleJpaRepository.findAll(Iterable<ID>) as OpenJPA still doesn't correctly bind in-clauses by name. This has been originally reported in [0] and marked fixed for 2.3.0 but even an upgrade to this version (coming in a subsequent commit) requires the workaround.
[0] https://issues.apache.org/jira/browse/OPENJPA-2018
When a parameter was listed with parentheses we didn't detect a custom binding and fell back to the standard binding. This effectively disabled the array-to-collection binding which is currently necessary for in bindings as some persistence providers do not bind arrays to in-clauses correctly.
Tweaked the regular expression to detect the bindings to accept the optional parentheses.
Previously, the reference documentation was missing details of how to set up EntityManager instances for usage of Spring Data JPA repositories in a CDI context. Augmented the section on complete manual setup but also added an example of the necessary setup in a pure JavaEE context.
Query parameter binding replacements were undone if a simple binding was contained in the query. Fixed that and also make sure we don't create superfluous multiple bindings for the same variable and binding type.
We now always create a ParameterBinding for all parameters to simplify the client code so that it can safely always lookup bindings and apply them.
Changed the setup of the regular expression to work with the keywords provided by the binding types to ease future extensions.
Added integration test to quickly verify the EclipseLink bug we're running into now for further reference.
Original pull request: #56.
Enhanced binding of parameters in StringQueryParameterBinder to be able to deal with situations where a parameter value has to be converted to be correctly bound e.g. for parameter values in IN-expressions.
We now only convert array values to collections if the value is to be bound in the context of an IN-parameter. Previously we erroneously always converted an array value to a collection value which lead to problems if an array value was meant to be used "as-is" e.g. in cases where an user wants to query for a certain byte[].
Original pull request: #56.
QueryUtils now only creates a join for collection properties that are explicitly annotated with an @ManyTo… annotation. This allows collection like properties like byte[] be referred to as non-collection property and thus not trigger a join when a derived query is created.
Accessing the legacy persistence provider class in Hibernate 4.3 causes a warning being logged. As we generally want to detect the presence of Hibernate in general only, we now check for the Hibernate 4.3 persistence provider interface first to immediately find the new interface and thus avoid the warning.
Upgraded to Hibernate 4.3.1.
Since the location of the Hibernate EntityManager implementation changed in Hibernate 4.3 to org.hibernate.jpa.HibernateEntityManager, we now support org.hibernate.jpa.HibernateEntityManager as well as org.hibernate.ejb.HibernateEntityManager as a Hibernate PersistenceProvider.
Original pull request: #55.
Latest Hibernate 4.3 releases have changes some behavior and internals slightly. Adapted the test cases accordingly and added another guard in JpaMetamodelEntityInformation to adhere to the new behavior.
Added build profile to be able to build against Hibernate 4.3.
Previously sorting by property of an associated object generated an inner join instead of a left join with QueryDsl and Hibernate. That excluded records that had null values on their join columns. We now generate appropriate left joins if we detect associations in the sort property expression.
Ignored test cases for EclipseLink since eclipse link generates an inner-join instead of an outer-join to fetch associations in order by. Filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=422450
Original pull request: #53.
ExpressionBasedStringQuery now resolves and evaluates SpEL expressions of the actual query in the constructor and passes the resolved query to the StringQuery constructor. This enables the alias detection mechanism to work properly.
Original pull request: #51
So far, ClasspathScanningPersistenceUnitPostProcessor threw an IndexOutOfBoundsException on Windows as the OS-specific file separator doesn't match the forward slash used in the URI. This is fixed by modified scanForMappingFileLocations() to use '/' to build up the resource path.
Original pull request: #44.
Corrected documentation to reflect the actual state of the @Modifying annotation which is that the clearAutomatically attribute is set to false by default. The implications of setting this attribute to true (which causes all pending non-flushed changes to be dropped) are now stated clearly.
Original pull request: #43.
The CriteriaQuery implementations unfortunately is not thread-safe for some persistence providers. E.g. Hibernate changes the state of it's implementation during the first attempt to use the instance. This causes multi-threading issues if we cache the query instance for later usage (as the instance might be used concurrently).
We now synchronize the first usage of the cached CriteriaQuery instance to guard against this situation.
Original pull request: #42.
When building Expression instances for attribute traversals we now inspect the mapping annotation to detect non-optional associations and prevent an extra left join from being created. This is because the join is only necessary to not drop null values from the result.
Added integration tests for Hibernate, EclipseLink and OpenJpa. EclipseLink needs a bit of special treatment as it exposes the inner join being created for a plain ….get(…) attribute traversal.
QueryUtils now checks already existing joins and reuses them when building expressions. Inspired by the pull request #41 by Alexandre Payment but polished and added integration test to make sure the joins really get reused.
Improved existingin order by detection to detect the existing clause independent of the case. Before we only detected lower case "order by" expressions.
We now make sure an alternative EntityManager (producer) is overriding a previously found EntityManager. Vice versa, we do not override a previously found one, except it marked as alternative.
