Introduce a builder API to register PropertyValueConverters using simple (Bi)Functions. Additional methods on ValueConversionContext to enable advanced use cases in converter implementation. Tweak generics of VCC to be able to expose store-specific PersistentProperty implementations via the context.
See #1484
Original pull request: #2566.
Move to @PersistenceCreator as canonical annotation to explicitly express constructors and methods to be used to create domain object instances from persistence operations. Removed @FactoryMethod as it's not needed anymore. @PersistenceConstructor is now deprecated.
Renamed EntityCreatorMetadata(Support|Discoverer) to InstanceCreatorMetadata(Support|Discoverer) to avoid further manifestation of the notion of an entity in the metamodel as it's not used to only handle entities.
Issue #2476.
Moved Vavr collection converters into a type in the utility package. Register the converters via CustomConversions.registerConvertersIn(…) to make sure that all the Spring Data object mapping converters automatically benefit from a ConversionService that is capable of translating between Java-native collections and Vavr ones.
Issue #2511.
This way they can be combined with different variants of CrudRepositories.
This affects
`PagingAndSortingRepository`, `ReactiveSortingRepository`, `CoroutineSortingRepository`, and `RxJavaSortingRepository`.
Any repository implementing those interfaces now needs to also implement a suitable CRUD repository, or needs to manually add the methods from a CRUD repository as needed.
Closes#2537
Original pull request: #2540.
Use var instead of explicit local types where applicable. Use pattern variable instead instanceof and cast. Prefer loops and nullable types over Stream and Optional. Convert classes to records where applicable.
See #2465
We now support configuration of the class loader in SimpleTypeInformationMapper to use a configured class loader instead of falling always back to the default/contextual class loader. In arrangements where the contextual class loader isn't able to provide access to the desired classes (e.g. parallel Streams, general Fork/Join Thread usage) the contextual class loader may not have access to the entity types. By implementing BeanClassLoaderAware, we can now propagate a configured class loader.
Closes#2508
A few further tweaks: ClassTypeInformation now never unwraps the user type to consistently work with the type originally presented in the lookup. That allows us to get rid of the custom equals(…)/hashCode() methods and removes the need to deal with original and user type in the same CTI instance.
The augmented caching of PersistentEntities in AbstractMappingContext now primarily happens in doAddPersistentEntity(…). We still need to implement a cache manipulation for the case that a user type has caused the creation of a PersistentEntity first and we see a lookup for the proxy type later. Before actually processing the TypeInformation we now try to lookup an already existing PersistentEntity for the user type and augment the cache if one was found.
See #2485
Original pull request: #2486.
Remove isProxyTypeInformation from TypeInformation. Use computeIfAbsent to fall back to user type information when attempting to add a entity to the MappingContext.
See #2485
Original pull request: #2486.
This commit makes sure to only create a PersistentEntity for an actual user type. Therefore ClassTypeInformation now considers the given type and not only the user one for both equals and hashcode. This makes sure we can distinguish TypeInformation for a proxy from the one of a user class.
The AbstractMapping context will take care of unpacking proxied types and registering the created entity for both the user as well as the proxy type information.
Prior to this commit build time generated proxy instances would have been able to pollute the context depending on the order they had been served by the initial entity set.
Closes#2485
Original pull request: #2486.
We now consider a qualified property path when registering and querying `QuerydslBindings` to ensure that paths matching various domain types do not accidentally get applied for a different type than they were registered for.
Previously, a binding for `Address.description` would be also applied to `User.description` as only the property path `description` was considered when looking up bindings.
Closes: #2418
Original Pull Request: #2422
We now publish events from deleteInBatch and deleteAllInBatch methods to consider well-known repository methods.
We also now prevent event publication if the method argument is not an instance of the domain type.
Closes: #2448.
We now reuse generated ObjectInstantiator classes instead of attempting to redefine classes with the same name. Redefinition leads to LinkageError and thus to the use of reflection-based instantiators and an increased allocation rate due to the failed attempt of class redeclaration.
Closes: #2446.
When an infinite Stream was handed into StreamUtils.zip(…) as first argument, the resulting stream was infinite, too, while inverting the argument order was limiting the resulting stream to the length of the finite one. This is now fixed by actually evaluating whether we can advance on both of the streams and shortcutting the process if that is not possible on either of the streams, limiting the processing of the overall Stream to the shorter of the two as already advertised in the Javadoc.
Fixes#2426.
Un-deprecate constructor. Rearrange method arguments to match parameter significance. Reformat code, replace space indents with tabs.
Original pull request: #2403.
We now configure explicitly the JsonProvider that is used by JSONPath through JsonProjectingMethodInterceptorFactory to avoid misconfiguration due to JSONPath defaulting attempts. Accepting JsonProvider allows for improved flexibility during configuration.
Closes#2403
This causes us to inspect the most concrete type we can find from a property declaration that might be overridden using an annotation.
Closes: #2409
Original Pull Request: #2410
We now name methods returning a TypeInformation<?> …TypeInformation() and ones that return Class<?> …Type(). In case of both flavors provided, overloads should move to the TypeInformation-based variant as the other one simply resolves ….getType() on the returned value.
Closes: #2408
Original Pull Request: #2410
