We now correctly inspect the sort parameter values and also fall back to the default if a single, empty parameter value is given.
Related ticket: DATACMNS-408.
Related pull request: #138.
Added hint to which constructor of the superclass to override. Added test cas e to make sure the expected types are advertised in the case of an error.
Linked back to the release train names from the section on dependency management with Boot for clarity. Added additional line break to avoid the first line in the repositories.adoc being interpreted as text.
Added sections to the reference documentation to elaborate on the newly introduced web integration for Querydsl.
Added documentation for Future<T> return types.
Corrected the closing tag for dependency for Spring Data Commons section on dependencies. Fix broken links to Spring Framework reference documentation. Update build requirements in readme.
Original Pull Request: #137
If standard Querydsl StringPaths are used without any reference to a query class tree, we previously dropped the first segment of the path expression.
Moved to a completely different algorithm to determine the path by just using the Path's toString() representation and the root removed if necessary.
If a keyword was contained in a complex property path (like In in SomeInfo), the property path was invalidly cut of in the middle. We now simply use the length of the keyword to extract the actual property from the candidate. This should be faster anyway as it doesn't require another lookup of the pattern in the source candidate.
Related pull request: #136.
The JavaDoc of PersistentPropertyAccessor now explicitly hints to PersistentEntity.getPropertyAccessor(…) to make obvious how instances of it can be obtained.
Moved all Querydsl related bean definitions and customizations to a dedicated configuration class that only gets included if Querydsl is on the classpath.
Extracted a QuerydslActivator for use in Spring Data REST, which uses HateoasAwareSpringDataWebConfiguration via inheritance, not via @EnableSpringDataWebSupport.
Previously, we exposed a QuerydslBindingsFactory as bean method return type which breaks Spring bootstrap even if it's lazy due to its references to Querydsl types.
Related tickets: DATACMNS-669.
QuerydslBindingsFactory creates a completely build up and customized QuerydslBindings instance for a given QuerydslBinderCustomizer type and domain type.
This basically involves creating or obtaining an instance of the customizer with the following algorithm:
1. If an explicit customizer type is given and no BeanFactory is configured, we'll simply instantiate the configured type. This allows simple customizer implementations with a no-arg constructor.
2. If a BeanFactory is configured and a customizer type configured, we're trying to locate a bean of that type in the BeanFactory, falling back to creating an instance of the customizer through the BeanFactory if no existing bean definition can be found. This allows unique customizer bean definitions or complex prototype scoped customizer beans created on the fly.
3. If no customizer type is configured, we check whether the the repository of the domain type implements QuerydslBinderCustomizer and use it if so.
The extraction of that functionality allows that algorithm being used by Spring Data REST, although only step 3 is currently used there as no explicit customizer can currently be configured with Spring Data REST.
PointFormatter error message now states it's expecting comma separated values. Previously it erroneously reported expecting a semicolon.
Original pull request: #134.
We now default to a FormattingConversionService to make sure comma-separated values are transformed into arrays correctly. Also, we now build up dedicated TypeDescriptor instances for the property or field about to be bound to potentially pick up formatting annotations on those.
We now convert comma separated values for an array property by splitting values and converting each of them. This allows to convert address.location=40.740337,-73.995146 to
class Address {
Double[] location;
}
To prevent classes from being garbage collected due to Class<?> references within DefaultParameterNameDiscoverer we no keep all ParameterNameDiscoverer instances in a non-static field.
Introduced dedicated querydsl.bindings package to contain all non-web projects to make sure domain types and repositories don't have to depend on types in a web package.
Updated Sonargraph architecture description accordingly.
Original pull request: #132.
Mostly Javadoc. Removed all API that took String paths so far.
Changed return type of bean definition for QuerydslPredicateArgumentResolver to HandlerMethodArgumentResolver so that Querydsl stays optional during class loading.
Original pull request: #132.
If no QuerydslBinderCustomizer is configured on @QuerydslPredicate specifically, we now also consider the domain types repository as candidate for binding customization.
The lookup algorithm for explicitly configured customizers has been refined to try to find a bean in the BeanFactory first, resorting to on-the-fly creation eventually.
QuerydslPredicateArgumentResolver is now registered as a lazily initialized bean and its usage is guarded by checking presence of Querydsl itself.
The according test needs to do some reflection in order to stay out of trouble when types are loaded by different class loaders required to hide certain types.
Original pull request: #132.
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.
Oliver Gierke
Ruben Dijkstra
Christoph Strobl
Martin Grigorov
David Syer
Thomas Darimont