[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3799) PersistentSet does not honor hashcode/equals contract when loaded eagerly

[Shawn Clowater (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45659#comment-45659 ] 

Shawn Clowater commented on HHH-3799:
-------------------------------------

Nate, therein lies the rub.  Even if you're using the ID as the hashcode/equals then the hashcode changes between a saved and unsaved entity (for a generated identifier).

Removing and re-adding doesn't work quite right either.  You can't remove an object where the hashCode changes from a set since the underlying store is a hashMap keyed off the hashcode so it can't be found using a set.remove(object)

In our case we generate (and persist) a UUID to identify our objects so that we can marry them up from UI to our command layer and back again.  This is separate from our PK since users get in the way and complain if they see an entity with a 32 char alphanumeric PK vs a long generated from a sequence.  In a perfect world I'd use UUID identifiers that were assigned at object creation but alas.

While I agree that it may be a slippery slope of keeping a hash of n number of mutable properties it shouldn't break eagerly loaded collections.  As for the proxy thing I'd love to see the ability to specify an additional property as 'eager' w/o having to instrument all of the classes to get property by property lazy loading.

> PersistentSet does not honor hashcode/equals contract when loaded eagerly
> -------------------------------------------------------------------------
>
>                 Key: HHH-3799
>                 URL: https://hibernate.onjira.com/browse/HHH-3799
>             Project: Hibernate ORM
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.3.1, 3.5.1
>            Reporter: Igor Vaynberg
>            Assignee: Gail Badner
>         Attachments: test.zip
>
>
> when persistent set is loaded eagerly in some situations it calls hashcode on its items before their field values are populated and then uses this incorrect hashcode to store them in the set. this makes set items inaccessible by any collection items that rely on hashcode such as contains(), remove(), etc.
> attached is a simple maven test project that reproduces the error, unzip and mvn test to run the test.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira