Create PersistentEntity only for user class in case of proxy instance. #2486
Conversation
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.
|
Since the related issue breaks MongoDB support in Spring Native I can validate it works with snapshots once merged. |
|
@sdeleuze – Sure thing! |
There was a problem hiding this comment.
Does it make sense to avoid TypeInformation.isProxyTypeInformation() and change the client code to simply compare the original TypeInformation instance with the one returned from ….getUserTypeInformation()? That'd avoid leaking the proxy case into the API and keep the abstraction to "there's a case in which the original user type is different from what we deal with" without revealing the cause.
|
That was exactly my thought too, to not expose |
|
I think that wouldn't work currently, as I guess it might still be helpful to expose |
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.
|
That's merged now. |
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.
|
I have been able to run our |
This PR makes sure to only create a
PersistentEntityfor an actual user type. ThereforeClassTypeInformationnow considers the given type and not only the user one for both equals and hashcode. This makes sure we can distinguishTypeInformationfor a proxy from the one of a user class.The
AbstractMappingcontext 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