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 look up bean definitions for repositories using BeanFactory.getMergedBeanDefinition(…) to consider parent-child relationships across application contexts.
As we iterate through bean definitions considering ancestors we need to allow parent bean definitions. Previously, we obtained the bean definition from the child context and since the bean was inherited from the parent, the child context cannot provide a bean definition.
Closes#2383
Original pull request: #2384.
FluentQuery allows extending a query specification initially defined by a Example probe or a Querydsl Predicate and fetching the actual result through a functional programming model:
interface PersonRepository extends QuerydslPredicateExecutor<Person> {
<S extends T, R> R findBy(Predicate predicate, Function<FluentQuery.FetchableFluentQuery<S>, R> queryFunction);
}
PersonRepository repo = …;
List<PersonProjection> result = repo.findBy(QPerson.person.name.eq("Walter"), q -> q.sort(Sort.by("lastname")).as(PersonProjection.class).all());
Closes: #2228
Original pull request: #2421.
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.
We now use an explicit lookup via the application context to consume PageableHandlerMethodArgumentResolverCustomizer and SortHandlerMethodArgumentResolverCustomizer rather than autowiring those into a field.
Fixes#2440.
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.
Extract adding the actual entity to the MappingContext into its own method along with error handling spanning the entire entity initialization process.
See #2329
Original pull request: #2367.
When an error happens inside the AbstractMappingContext, the caching sometimes gets corrupted. That's because some exceptions are caught, others are not. Instead, the error handling that clears out the cache needs to be shifted up one level, resulting in a simpler code block.
Closes#2329
Original pull request: #2367.
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
Using JpaEvaluationContextExtension with reactive infrastructure in place, ReactiveExtensionAwareEvaluationContextProvider can lead to IllegalStateException if the desired extension doesn't match the predicate instead of being silently dropped.
Closes#2392
Original pull request: #2393.
A public bean method that returns a private type is unusual and prevents the processing of such bean in reflection-free use cases. There was also an unnecessary qualifier in the implementation.
Closes#2399
Unified the calculations made for entityTypeInformation and entityTypes in AbstractPersistentProperty. This avoids both calculations getting out of sync. Also we avoid premature calculation abortions if SimpleTypeHolder.isSimpleType(…) returns true for the raw property type. The latter has caused issues for collection properties in Spring Data KeyValue which considers everything in java.util a simple type.
Related ticket: #2390.
Reduce TypeDiscoverer.isNullableWrapper method visibility to private to avoid exposure in preparation for wider value type support.
Original pull request: #2394.
See #2390.
When inheritance is used for aggregates, lookups of the repository for a Child aggregate instance have so far failed to return a repository registered for the Parent. Client code had to consider that scenario explicitly.
This commit introduces an additional lookup step in case we cannot find a repository for an aggregate type immediately. In this case, we then check for assignability of any of the known aggregate types we have registered repositories for and the type requested. I.e. for a request for the repository of Child, a repository, explicitly registered to manage Child instances would still be used. In the sole presence of a repository managing Parent instances, that would be returned for the request for Child, too.
Original pull request: #2406.
We now no longer return a null Predicate from QuerydslPredicateBuilder.getPredicate(…) if the input values are empty or if the constraints are empty. Instead, we return an empty BooleanBuilder instance to avoid null handling on the calling side.
HandlerMethodArgumentsResolvers for QuerydslBindings retain their null/Optional.empty semantics.
Closes#2396
We now retain properly the collection of orders by using accessor methods instead of relying on using the orders field. TypedSort orders are not using the orders field, instead they iterate over recorded persistent property paths.
Closes#2103
Original pull request: #2377.
We now validate declared annotations by pre-processing these through AnnotatedElementUtils to ensure a proper comparison. Previously, we compared annotation in their declared form (AnnotatedElement.getAnnotations()) with merged annotations which could fail due to aliasing effects of merged annotations.
Closes#2368.
getTargetRepositoryViaReflection accepting Class has a misleading name as it lets assume that the returned instance is a repository. In fact, this method looks up a matching constructor for the given arguments and creates an instance.
Closes#2361
Previously, we tried to invoke the copy(…) method on all Kotlin classes whereas the copy(…) method is only specific to Kotlin data classes.
Original pull request: #390.
Closes#2358.
Skip shadowed properties that are not assignable to their shadowing type.
Extend tests. Document property overrides.
Original pull request: #390.
See #1911.
Prior to this commit, the lookup of types to be added as persistent entities for a given PersistentProperty used the actual property type which did not consider the association target type at all. Removed the usage of Optional for the entity type information and switched to use TypeInformation for the raw association target type so that it can be considered in ….getActualType().
We now throw MappingInstantiationException with a nested BeanInstantiationException in alignment to ReflectionEntityInstantiator when attempting to create a new instance of an abstract class.
Closes#2348.
We now detect the component type of jMolecules' Association as association target type in AbstractPersistentProperty. AnnotationBasedPersistentProperty keeps the lookup of the explicit @Reference around but falls back to the Association analysis for that.
@Reference is now only considered by AnnotationBasedPersistentProperty. It was previously also (erroneously) considered by AbstractPersistentProperty.
It was also changed to return `null` in case no association target type could be looked up instead of returning the sole property's type in case that is an entity. This was done to satisfy the behavior documented on the interface but also to avoid the call to isEntity() during the calculation which might use association information in turn and thus lead to a stack overflow. Reworded the contract of PersistentProperty.getAssociationTargetType() to emphasize the symmetry with ….isAssociation() in implementation classes.
Closes: #2344.
