The intend of WindowIterator is to support users who need to iterate multiple windows. It keeps track of the position and loads the next window if needed so that the user does not have to interact with the position at all.
Also remove the Window methods to get the first/last position and enforce the index based variant.
Update the documentation to make use of the newly introduced API.
See: #2151
Original Pull Request: #2787
Imports, Javadoc, ticket references in test cases.
Removed the need for MethodParameterAware… flavors of the ResourceAssemblers by keeping the MethodParameter reference in the original assemblers in the first place. Extracted common Pageable MethodParameter lookup code into PageableMethodParameterUtils.
Related ticket: #1307.
Added SlicedResourcesAssembler to esaily convert Slice instances into SlicedResource instances and automatically build the required previous/next link based on PageableHandlerMethodArgumentResolver present in the MVC configuration. The assembler can either be injected into a Spring MVC controller or a controller method. The latter will then assume the controller methods URI to be used as pagination link base.
Added necessary SlicedResourcesAssemblerArgumentResolver and MethodParameterAwareSlicedResourcesAssembler classes and wire up HateoasAwareSpringDataWebConfiguration configuration beans to that SlicedResourcesAssembler's can be auto-injected into controllers.
Closes#1307
Use consistently domain type instead of introducing a new terminology to repository infrastructure.
Rename Kotlin variant of ParameterUnitTests to KParameterUnitTests to avoid duplicate classes.
See #2770
Original pull request: #2771
To support the binding of Class parameters to queries for declared query methods, we have to be able to differentiate them from Class parameters that are supposed to represent projections. We can do that by relating the declared Class' element type to the aggregate root type as a Class typed to that or any subtype of it will never trigger a projection by definition.
So far the Parameter(s) abstraction was solely created from a query method's Method. We now changed that for QueryMethod to forward the aggregate type detected on the RepositoryMetadata and consider it during the detection of dynamic projection parameters.
As a mitigating measure, we now also support @Param on Class-typed parameters to explicitly mark them for query binding. This is primarily to be able to add this support to the 2.7
The changes are built in a way that modules extending that mechanism will continue to work as is but see deprecation warnings on methods and constructors involved. Adapting extending code to the new APIs will automatically enable the support for bindable Class parameters on query methods.
Fixes#2770.
Original pull request: #2771
Also update the type filter that would not mach types directly present in the given package.
Modify type contribution method to allow store specific override.
Closes: #2744
Original pull request: #2746
Added dedicated Lazy.toString() rendering the resolved value's ….toString() method but resorts to a constant [Unresolved] if it's not already resolved. An additional ….toString(Supplier<String>) allows to customize the fallback message if needed.
Fixes#2751.
A message like, "No property 'creat' found for type 'User' Did you mean ''created''" is now properly formatted as:
"No property 'creat' found for type 'User'; Did you mean 'created'".
Closes#2750.
This commit introduced support for registering GraalVM native reflection type hints for Querydsl Q types that target domain types used in the repository interface declaration.
At this point we only do a simple lookup for Q types based in the very same package that implement EntityPath.
More advanced configuration (eg. base package and type prefix), potentially available via EntityPathResolver are not taken into account as this would require eager bean resolution from the application context, which is likely to trigger additional infrastructure. In this case the user is required to register Q types manually.
Closes: #2721
Original pull request: #2743.
ReactiveWrappers is not tied to repositories so it does not need to reside in the repository.util package. This utility is now located in the data.util package for a better module design and to prevent package cycles.
See #2708
We now consider the the actual repository & fragment bean name when checking for existing bean definitions of default custom implementation beans. Previously, we used the repository interface name without considering the repository bean name.
Closes#2487.
Original Pull Request: #2488
We now replace ManagedTypes bean definitions with generated code that contain the discovered types to avoid class path scaning.
Closes: #2680
Original pull request: #2682.
We now fall back to the canonical constructor of records when we cannot disambiguate which constructor to use.
Also, reflect the Kotlin persistence creator mechanism.
Closes#2625
Original pull request: #2694.
We now consider the correct argument type instead of checking assignability of the actual property type against the input value.
Closes: #2649
Original Pull Request: #2650
We now try to read the types directly from the bean definition arguments first, before attempting to resolve the actual bean instance.
If resolving the bean fails, we currently only log an info message. This arrangement needs to be revisited.
See: #2593
This avoids having to touch modules to add something like ImportRuntimeHints(AuditingHints.ReactiveAuditingRuntimeHints.class) to the enabled auditing annotations.
Original Pull Request: #2624
* Refactored logic in AOT infrastructure classes.
* Annotated AOT API with Spring's @NonNull and @Nullable annotations.
* Edited Javadoc.
* Introduced PredicateUtils abstract utility class encapsulating common Predicates on types and class members.
* Added comments for review and clarification.
Original Pull Request: #2624
This commit introduces initial support for framework 6 bases ahead of time processing of data components and adds extension points for module implementations.
See: #2593
Original Pull Request: #2624
We now provide an abstraction to describe a collection of entity types that can be provided to the mapping context as improvement over `Set<Class>` for easier context setup.
Original pull request: #2635.
Closes#2634.
Slight refinements in TypeDiscoverer.equals(…) / hashCode() that are still not completely valid, are different enough to work for differentiating use cases but not 100% efficient for cache cases. Captured outstanding work in spring-projects/spring-data-commons#2643.
Reimplemented ….repository.query.Parameter.isDynamicProjectParameter(…) to bild on TypeInformation completely and properly unwrapp *all* wrapper types for type comparison.
Related ticket #2312.
Mark Paluch
Christoph Strobl
Oliver Drotbohm
Michael Schout
John Blum
Jens Schauder