Enables reachability analysis. Previously, the presence checks were using method invocations and the AOT processing isn't following the methods.
Original Pull Request: #2624
This avoids having to touch modules to add something like ImportRuntimeHints(AuditingHints.ReactiveAuditingRuntimeHints.class) to the enabled auditing annotations.
Original Pull Request: #2624
We now provide PropertiesBasedNamedQueriesFactoryBean to create PropertiesBasedNamedQueries directly bypassing indirections through PropertiesFactoryBean and PropertiesBasedNamedQueries.
Original Pull Request: #2624
We provide an initial set of runtime hints required to spin up data repositories on GraalVM native image.
Additionally we skip synthetic types during type inspection.
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're now unifying the lookup of a unique identifier for a Spring Data module in the RepositoryConfigurationExtension interface. Previous users of getModulePrefix() in subclasses of RCE should rather call getModuleIdentifier(). Implementations of RCE that previously implemented getModulePrefix() directly should rather switch to implementing getModuleName() and additionally getModuleIdentifier() in case the default implementations derivation of the identifier from the name doesn't produce the results intended.
RepositoryConfigurationExtensionSupport.getDefaultNamedQueryLocation() was changed to rather use the identifier to calculate the name of the named query location instead of the prefix.
Fixes#2644.
This is a breaking change as many modules implement a protected method. We're going to change this later with #2644.
Original pull request: #2635.
See #2634.
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.
We now provide PropertiesBasedNamedQueriesFactoryBean to create PropertiesBasedNamedQueries directly bypassing indirections through PropertiesFactoryBean and PropertiesBasedNamedQueries.
Resolves: #2584
Original Pull Request: #2596
Reworked the implementation of the TypeInformation type hierarchy to be based on Spring's ResolvableType for most of the heavy-lifting.
Original pull request: #2572.
Related ticket: #2312.
Spring Data Commons has a hard-coded list of special types than can be included in query methods including Pageable and Sort.
A custom finder with PageRequest, even though it extends Pageable, will fail when it would work fine with a narrowed input. This extends the list using an assignability check.
Related: spring-projects/spring-data-jpa#2013
See #2626.
We now return a default value for invocations of methods returning a primitive value to pass the AOP infrastructure's check for compatible values. Before, that barked at the null value returned for the invocation.
Fixes#2612.
Removed the removal of the general collection-to-object converter as apparently some downstream Spring Data modules rely on it. This theoretically allows conversions of collections into maps but we now simply don't assume that not to work anymore.
Issue #2619.
Custom collection support is now centralized in ….util.CustomCollections. It exposes API to detect whether a type is a map or collection, identifies the map base type etc.
Support for different collection implementations is externalized via the CustomCollectionRegistrar SPI that allows to define implementations via spring.factories. The current support for Vavr collections has been moved into an implementation of that, VavrCollections.
Unit tests for custom collection handling and conversion previously living in QueryExecutionConverterUnitTests have been moved into CustomCollectionsUnitTests.
Fixes#2619.
* Annotates the API with Spring's @NonNull and @Nullable annotations.
* Re-instates the hasValueConverter(:PersistentProperty) method.
* Removes explamation mark in Exception messages.
* Uses Java 17 language features to simplify code.
* Edits Javadoc.
Closes#2617.
Rename generics from C extends PersistentProperty to P extends PersistentProperty.
Refine conversion setup. Make PropertyValueConversions.getValueConverter(…) to return non-null. Return PropertyValueConversions from CustomConversions.
Resolves#2577Closes#2592
PropertyValueConverter read and write methods are never called with null values. Instead, PropertyValueConverter now defines readNull and writeNull to encapsulate null conversion. PropertyValueConversionService is a facade that encapsulates these details to simplify converter usage.
Resolves#2577Closes#2592
* Re-implement getNumberOfOccurrences(..) in terms of a Stream.
* Deprecate the mispelled getNumberOfOccurences(..) method and delegate to the new getNumberOfOccurrences(..) method.
* Edit Javadoc.
Closes#2600.
Looking up a PersistentEntity via ….getPersistentEntity(…) applies some massaging of the given type as it could be a proxy type created for a user type. That wrangling was not applied in ….hasPersistentEntity(…) which resulted in a call to that method with a proxy type yielding false although it shouldn't if we already have a PersistentEntity available for the corresponding user type.
We now explicitly lookup the entity by original type and, if it's not the user type itself, try to look up the entity for the latter.
Fixes#2589.