You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From my analysis, the regression has been added by commit c866b4202527b3acc64e7cc205a98a8aa754cb59 where "ClassTypeInformation now never unwraps the user type to consistently work with the type originally presented in the lookup..."
The assumption in that comment might be incorrect, I would be surprised if PersistentEntity instances are mapped against an HibernateProxy class.
I believe that at least ClassTypeInformation.from(Class type) should have retained the type unwrapping.
This is a minimal demonstrating project which also shows the impact on Spring Data REST demo.zip
The text was updated successfully, but these errors were encountered:
The change is more invasive than anticipated. Prior the unwrapping change, looking up the persistent entity using the proxy type worked because ClassTypeInformation unwrapped the type before constructing TypeDiscoverer. That has led to the successful lookup through the proxy. We need to fix this regression.
mp911de
changed the title
AbstractMapping.getPersistentEntity(Class<?> type) fails to lookup the PersistentEntity when the provided type is a HibernateProxyAbstractMapping.getPersistentEntity(Class<?> type) fails to lookup the PersistentEntity when the provided type is a HibernateProxyDec 8, 2021
Trim trailing white spaces. Introduce getRequiredMetamodel(…) to refine nullability handling. Use diamond syntax and method handles where possible.
See #2383
We now unwrap the user type in JpaMetamodelMappingContext.shouldCreatePersistentEntityFor(…) to enable usage of proxy types when requesting a PersistentEntity.
Previously, we checked against the proxy type which is not managed by the JPA meta-model.
Closes#2383
Trim trailing white spaces. Introduce getRequiredMetamodel(…) to refine nullability handling. Use diamond syntax and method handles where possible.
See #2383
From my analysis, the regression has been added by commit c866b4202527b3acc64e7cc205a98a8aa754cb59 where "ClassTypeInformation now never unwraps the user type to consistently work with the type originally presented in the lookup..."
The assumption in that comment might be incorrect, I would be surprised if PersistentEntity instances are mapped against an HibernateProxy class.
I believe that at least ClassTypeInformation.from(Class type) should have retained the type unwrapping.
This is a minimal demonstrating project which also shows the impact on Spring Data REST
demo.zip
The text was updated successfully, but these errors were encountered: