As originally discussed here:
I'm encountering an issue with changes made in 4.3.5.Final (and 4.2.12.Final) via related to Proxy narrowing. A test case is attached which demonstrates the following behavior:
Given a model where:
#a class hierarchy where User is a parent class of AdvancedUser
#a class UserConfig with a many-to-one to User
When executing a query for a specific UserConfig, the getUser() returns a proxy of User.class. However, immediately executing a second (polymorphic) query for that same user directly, fails to return the AdvancedUser instance.
This works fine in 4.3.4.Final (and 4.2.11.Final). That is, this same code returns the proper AdvancedUser instance from the second query.
Note that EclipseLink goes one step further and merges fetched state through e.g. a JOIN FETCH query into existing objects which is what is about.
Interestingly, when bytecode enhancement is enabled getReference() for a polymorphic entity type returns the super/declared type instance whereas without bytecode enhancement, EclipseLink actually fetches and returns the subtype instance. So using getReference() with the supertype and then having a query that fetches the entity will result in an exception in EclipseLink because it fails to merge the fetched state into the instance due to expecting it to be of the correct subtype.
So the question remains, what should be returned when using getReference()? Should we also query the DBMS for polymorphic types or just return an instance of the given type? If we don't query the DBMS which is IMO better, we have to decide what happens when state gets merged back into that instance. Should it fail if the object is not of the appropriate type like in EclipseLink? Or should it just merge the state which is applicable for the type?
@Christian Beikov Have you received answers to your questions? What else is needed to get a fix in?
Sorry but we didn't agree on anything specific yet, but even then, this is not something that is going to be done anytime soon. I'll schedule it for 6.0 but can't make any promises.
Does this issue only affect versions 4.3.5, 4.2.12, and 5.2.4 as indicated in the ticket?
I am in the process of upgrading a 4.2.3.Final hibernate to either 4.2.21.Final or 4.3.11.Final or 5.3.X.Finaland we do have such use cases in our codebase.
Since this is a WIP issue with no ETA, is there a workaround fix for this issue?
I guess a workaround could be to join fetch the association or to load the object by id after removing the proxy from the persistence context with detach.