Javadoc on MultiValueBinding. Hide QuerydslBindings.bind(…), ….include(…) and ….exclude(…) methods that take String arguments to reduce the probability of no query class being present.
Refined the value handling for empty request values which are represented as String[] containing an empty String. We now massage those into an empty Collection for MultiValueBindings and a null value for SingleValueInvocations.
We currently skip property values that match this pattern entirely but are prepared to allow a configuration flip switch to handle those scenarios in the future. We currently stick to skipping those values to prevent the bindings from having to deal with null values.
We now also allow the bindings to return null to indicate they don't want to get applied in the resulting predicate at all.
Switched to interface based customization to make it easier to use customizations with Spring Data REST. Added Querydsl-specific adapter of RepositoryInvoker to allow Spring Data REST to hook in the execution of the predicate obtained from request parameters.
Original pull request: #132.
We now ignore invalid PropertyPaths on property binding to Querydsl Predicates. Those may occur since the request also holds non-property-related arguments, such as pagination parameters.
Fixed two potential NullPointerExceptions along the way since we no longer depend on the presence of @QuerydslPredicate.
Original pull request: #132.
QuerydslBindings now uses a builder style pattern to define custom bindings. This allows to define the same binding for multiple properties of the same type in one configuration call.
Introduced MultiValueBinding to be able to register a binding for multiple source values (i.e. if multiple values are provided for the same parameter). The previously named QuerydslBinding is now a SingleValueBinding which gets adapted to by extracting the first element of the values provided considered as collection.
Slightly refined the generics signature in QuerydslBinding for better type derivation in Lambdas. Removed the need for QuerydslBindingContext by moving a few properties around. The ConversionService instance is now piped into the QuerydslPredicateBuilder directly.
Added a bit of sample data to the Users test domain type to be able to execute the generated Predicates in tests to validate their correctness.
Original pull request: #132.
Adding @QuerydslPredicate to a parameter within SpringMVC Controller when having registered the QueryDslPredicateArgumentResolver allows to generate a Querydsl Predicate based on the request parameters.
Parameters will be converted into their corresponding property types before using the as predicate value. Given more than one attribute will connect those using 'and'. Collections of values will force usage of 'in' while single values on collection like properties result in 'contains'.
The base type for building the Querydsl Path is extracted from the methods return type. In case of non domain type return values it can optionally be specified via @QueydslPredicate(root = …). Specific Predicate conversions can be registered via '@QuerydslSpecification'.
This allows to sneak in specific property path handlings more easily.
new QueryDslPredicateSpecification() {
{
define(new StringPath("address.city"), (path, value) -> path.like(value.toString()));
}
};
Renamed resolver, accessor etc. to express operation of binding properties to a resolved path and introduced explicit binding context which allows reuse of predicate builder within the ArgumentResolver.
Added registration of QuerydslPredicateArgumentResolver directly in SpringDataWebConfiguration reusing the provided ConversionService.
Added Javadoc and changed visibility of non public API and types.
Original pull request: #132.
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).
Parameter now has a isExplicitlyNamed() to indicate whether the user explicitly assigned a name to it in contrast to an implicitly discovered parameter name.
We now leniently return null for the repository base class name from the AnnotationRepositoryConfigurationSource to make sure Spring Data modules compile against Spring Data Commons 1.10 continue to work on 1.11 without having the annotation attribute added.
A failure to resolve a property path into a PersistentPropertyPath now causes an InvalidPropertyPath exception being thrown. It captures the context of the failure like the resolved path, the offending segment. Added getPersistentPropertyPath(InvalidPropertyPath) that resolves the resolvable part for further use downstream.
Added null-checking assertions to AbstractMappingContext.getPersistentPropertyPath(…) variants. Improved DefaultPersistentPropertyPath to be able to append properties while building and to allow representing an empty path.
We now use Spring's PropertyMatches to build up the exception message and include a list of potentially meant properties.
Removed unused config file for tests along the way.
Original pull request: #125.
We now handle primitive and non-primitive arrays in ProxyProjectionFactory. WE basically skip element projections for the former and correctly implement exactly that for the latter.
When default transactions get disabled, we now still configure a TransactionInterceptor to make sure explicitly defined transactions are still applied. Previously the interceptor was not registered at all if default transactions were configured to be turned off and thus even explicitly declared transaction configuration was not considered.
Related tickets: DATACMNS-656.
We now make sure the converter for CompletableFuture is only registered if Spring 4.2 or better is on the classpath. Adapted test cases to only run tests for CompletableFuture support in the very same scenario.
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.
ProxyProjectionFactory now implements ResourceLoaderAware to be able to use the class loader used by the framework. SpringDataWebConfiguration now forwards the Application context as ResourceLoader through ProxyingHandlerMethodArgumentResolver into the target factory.
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, CompletableFuture, ListenableFuture) 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.
Spring Framework 4.2 is going to introduce support for CompletableFuture as return type for @Async methods. Support for Spring's ListenableFuture has already been supported in the framework 4.1. We've added the necessary infrastructure to allow these types as return types on repository methods, too.
Related tickets: SPR-13128.
Deprecate ObjectInstantiatorClassGenerator and provide a replacement
ClassGeneratingEntityInstantiator which doesn't retain a reference to
the context class loader.
Original pull request: #128.
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.
We're now using ClassUtils.getDefaultClassloader() to make sure we adhere to any class loading tricks the framework might impose for domain type instantiation.
Introduced QueryMethodParameterConversionException to capture the context of a failed ConversionException to allow better error reporting.
Cleaned up test cases to not use deprecated API anymore.
We now always render both first and last links in case the page returned is navigable, which essentially means: whenever the result spans across more than one page. I.e. whenever either a next or prev link will be rendered, both first and last links are rendered, too.
Clients can still reason about the fact whether they're on the first or last page by the non-presence of prev (indicates you're on the first page) or next (indicates you're on the last page).
We now add first and last links to the PagedResources created in line with the appearance of the prev and next links. The PagedResourcesAssembler can be configured to enforce the rendering using setForceFirstAndLastRels(…).
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.
PagedResourcesAssembler now creates the self, prev and next links for a PagedResource to be canonical and not contain any template parameters. This is to make sure a client can not actually tweak the links and follow a link that's not strictly conforming to semantics of the rel.
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.
RepositoryFactorySupport now exposes a setRepositoryBaseClass(…) to take a custom type that instances will be created reflectively for. This removes the need for a boilerplate repository factory and FactoryBean implementation to hook custom repository base class implementations into the infrastructure.
RepositoryFactorySupport now exposes a getTargetRepositoryViaReflection(…) method to allow sub-classes to create repository instances and consider customized repository base classes nonetheless. getTargetRepository(…) needs a tiny signature change which unfortunately requires imple
Fixed schema registration for version 1.8 schema. Added new XSD containing a base-class attribute on the <repositories /> element to customize the repository base class via XML.
Removed outdated section of how to create a custom base repository class from the reference documentation and replaced it with new simplified instructions.
Deprecated usage of factory-class attribute in configuration. Point users to newly introduced way of configuring a base class directly to avoid the need for a boilerplate repository factory and factory bean implementation.
DefaultRepositoryInformation now makes target class methods assignable before caching and returning them, so that they can always be invoked reflectively. Made this aspect part of the contract of RepositoryInformation.getTargetClassMethod(…).
DomainClassConverter as well as its internal ToEntity- and ToIdConverter implementations now actively refrain from matching if the source type is assignable to the target one to prevent unnecessary conversion attempts if the source value already actually is assignable to the target type.
Related ticket: DATACMNS-583.
Introduced a new overload for invokeQueryMethod(…) that uses a MultiValueMap with effective values of type Object so that clients can hand non-String values to the invocation. This is particularly useful if certain values shall trigger dedicated Converters registered in the ConversionService of ReflectionRepositoryInvoker.
Related tickets: DATAREST-502.
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.
In case a RepositoryMetadata implementation alters the domain type the repository is actually handling, we still have to be able to find the repository based on the type originally declared in the repository.
The newly introduced getAlternativeDomainTypes() is now used by Repositories to register a repository for all types returned by that method, too, so that this reverse lookup still works.
Removed the ability to configure a custom SpElExpressionParser for now as it's not really part of the performance optimization. Polished assertions in SpelEvaluatingMethodInterceptor.
Original pull request: #118.
We now allow a SpelExpressionParser to be configured on the SpelAwareProxyProjectionFactory. This parser is then passed on to SpelEvaluatingMethodInterceptor. We also now eagerly pre-parse any SpEL expression in @Value annotations on methods of the projection interface. This avoids repeated evaluations during the actual method invocations.
Original pull request: #118.
Introduced @SpringDataWebConfigurationMixing that can be used on configuration classes that are supposed to contribute components to the Application context when @EnableSpringDataWebSupport is used.
SpringDataWebConfigurationImportSelector scans the org.springframework.data package for classes annotated with that annotation and adds them to the classes to be considered config classes.
TrasnactionalRepositoryFactoryBeanSupport now exposes a setEnableDefaultTransactions(…) which, if disabled, causes the TransactionalRepositoryProxyPostProcessor not to be registered and thus no default transactions to be applied.
Related tickets: DATAJPA-685.
Extracted DefaultMethodInvokingMethodInterceptor from RepositoryFactorySupport and register it within ProxyProjectionFactory if the code is running on Java 8.
Original pull request: #117.
