We're now correctly stating that we're preferring the delete method that takes the entity as argument over the one taking the id to match what's actually implemented.
Refreshed the copy of AnnotationTransactionAttributeSource to pull in the JTA 2.1 support introduced in the Spring Framework class. Opened up a ticket [0] to improve Spring Framework to eventually be able to ditch the copies to prevent such scenarios in the future (the missing feature introduced that is).
Related issues: DATACMNS-715.
Extended Version value object to correctly dump a non-numeric last segment of a version string to parse. Incorrect source version strings now raise an IllegalArgumentException better explaining the cause.
Related tickets: DATACMNS-496.
We now implement EnvironmentAware and ResourceLoaderAware to respect the current environment setup when scanning for types. We use the ResourceLoader's ClassLoader if configured but indicate to fall back to the default one if none configured.
We now support collection executions in query derivation in combination with wrapper types like (Future, Optional) that wrap a collection, e.g. Future<List<User>>. Previously we used the "raw" return type which tricked our detection for Collection / Page / Slice executions.
Original pull request: #130.
We now leniently add the TransactionProxy marker interface to the repository proxy to opt-out of any further transaction handling potentially applied through @EnableTransactionManagement or its XML equivalent.
The interface will be introduced in Spring 4.1.7 / 4.2 RC2 so we're reflectively adding it if present. Might be something we can think of making less indirect for Fowler once 4.1.7 has been released.
On a last page the total handed into a PageImpl constructor might not necessarily fit the content as there's the change of an insertion or deletion between the calculated count and the retrieval of the content. We now leniently mitigate those differences if the page created is the last page of the result.
Related tickets: DATAJPA-728, DATACMNS-615.
In case we create a ParameterizedTypeInformation for a property we now also analyze the field-local generics information and add the discovered type mappings to the type variable map.
When traversing nested property paths, AbstractMappingContext.getPersistentPropertyPath(…) previously used the raw actual property type. If the property path contains a reference to a generically typed property, this causes the deeper paths not being resolved correctly.
We now explicitly use the TypeInformation of the property to retain generics information while traversing the path.
In case the PageableHandlerMethodArgumentResolver was configured to use one-indexed parameters, it wasn't defaulting the lower bounds for the page number. This caused indexes out of the allowed bound submitted causing an invalid index handed tor PageRequest. We now apply better range shifting before the bounds are applied.
Instead of manually using Introspector.getBeanInfo(…) we now use Spring's BeanUtils.getPropertyDescriptors(…) to benefit from some caching of descriptor instances as well as advanced support for fluent setters, default methods etc.
Original pull request: #122.
Re-added index and defaulting information to the section that documents the currents state of web pagination. Removed legacy pagination sections as they're not really documenting the very legacy support (that would not even work anymore).
Added explicit anchors where missing.
Added a dedicated dependencies.adoc that outlines the usage of the Spring Data release train BOM as well as the way one would customize the release train to be used with Spring Boot.
Also, we now explicitly list the Spring Framework version the release requires.
AnnotationBasedPersistentProperty now also caches the absence of properties that are expressed through accessors only. Previously the absence of a field caused us to skip the registration of the absence in the cache.
The custom factory created to extend all repositories with additional behavior needs to return the type of the custom repository base class from getRepositoryBaseClass(…) to make sure the infrastructure can use it to inspect the CRUD methods correctly. Previously the documentations showed an interface being returned.
Code formatting in the example and inline code highlighting.
