[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses

[Shawn Windler (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=comments#action_23944 ] 

Shawn Windler commented on HHH-1460:
------------------------------------

In my opinion, this should return null.  If I am using a discriminator to decide between subclasses, then the cache should respect the discriminator as well.

After looking through the source, I have located where a problem *may* lie.  When caching objects, an EntityKey is used as the key for the HashMap.  The hashcode for this is based on the rootEntityName, rather than the entityName, so all subclasses are cached as the superclass.  Any other subclass of that superclass can return any 'sibling' class as long as it provides a correct and already-cached id.

Correct me if I'm wrong.  I know that you guys have a lot more experience with this code than I do and I'd rather not break the caching.

If you could provide an explanation why rootEntityName was being used instead of entityName, that'd help me out.  Without going through all the code to understand it, I can't be sure that these changes will affect anything else.

---------------------------
Changes:
org.hibernate.engine.EntityKey.java:102 (the generateHashCode() method)
OLD:  result = 37 * result + rootEntityName.hashCode();
NEW: result = 37 * result + entityName.hashCode();

* Also, the equals( Object other ) would likely need to be changed to use entityName as well, in order to uphold the contract of hashcode(): http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode()
---------------------------

Note: This was the most recent issue involving this problem, so I added this comment here.  If there is a better place for it, please let me know and I will get it moved.

Let me know if you have any questions or if I can provide any more information.

> Inconsistent behavior when using Session.get() with multiple subclasses
> -----------------------------------------------------------------------
>
>          Key: HHH-1460
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.1.2
>  Environment: Hibernate 3.1.2
> HSQLDB 1.8.0.2
> Java 1.5.0_05-b05
>     Reporter: Seth Fitzsimmons
>  Attachments: ClassCastException.zip
>
>
> Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected).  When attempting to load it without prior loading, null is returned, as expected.
> Client and Partner both extend person and have discriminator values of 1 and 2, respectively.  There is a single entry in the database (a Client) with a PK of 0.
> This should be null:
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);
> It is.  However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist:
> Client client = (Client) getSession().get(Client.class, 0);
> assertNotNull(client);
>         
> // this should be null, not return a Client object (resulting in a ClassCastException)
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira