[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira