Re: [Springframework-developer] equals/hashCode for entities

[Colin S. <col...@ex...>]

I started a thread on there actually, but unfortunately I couldn't get 
Gavin to agree that it is worth enhancing Hibernate to support dynamic 
rehashing of the changed element in the Set on the id change, which I 
think is what is really needed...

http://sourceforge.net/forum/forum.php?thread_id=909482&forum_id=128638


Timo Verhoeven wrote:

>Hi!
>
>It might be a good idea to discuss these issues on the hibernate 
>forums/mailing lists. I could imagine, there are others who had these 
>problems before.
>
>
>Regards,
>
>Timo
>
>Am Dienstag, 29. Juli 2003 17:18 schrieb Colin Sampaleanu:
>  
>
>>jürgen höller [werk3AT] wrote:
>>    
>>
>>><quote>
>>>So, we make a hashCode with some smarts. First time hashcode is
>>>called, - if id is null/zero, then hashCode will forever return the
>>>same value, which is the same for all class instances. Inefficient,
>>>but doesn't cause Sets to barf.
>>>- but if is not-null/zero and hashCode has never been called while
>>>id was null/zero, then hashCode will retun a value based on the id.
>>>This means that loaded entities loaded form the db are treated
>>>efficiently.
>>>
>>>Still not that great in terms of efficiency for new entities, but
>>>efficient for old entities.
>>></quote>
>>>
>>>Interesting idea - a hashCode implementation that tracks if it has
>>>already been called with an empty ID... So "contains" and "remove"
>>>will work even after saving, but unfortunately only for this very
>>>instance. Calling "contains" with a freshly loaded instance (and
>>>the previously saved one in the collection) will still fail, as the
>>>freshly loaded instance will return an ID-based hash code that will
>>>not match the one in the collection.
>>>      
>>>
>>Hmm, I think your point shows that this technique is somewhat
>>dangerous. I think it might break Hibernate's saveOrUpdate
>>functionality in some cases. You can not have a new object which is
>>added to a session (therefore it had an empty id and was added as
>>such to the collection, and then come along with a transient version
>>of the same object (which was built up in a different order (ie not
>>added to a collection before the id was set), coming in as a child 
>>in a collection inside a parent object, and call saveOrUpdate
>>reliably. That is, Hibernate would know if the object needs to be
>>saved or updated ok, but on an update would not be able to get the
>>same initial instance to update.
>>
>>bummer...
>>
>>    
>>
>>><quote>
>>>Also, there is still an issue with any collection (ie not HashSet)
>>>that uses 'equals', since that is going to change when the id
>>>changes. </quote>
>>>
>>>But that doesn't matter as such a collection will just call "equals"
>>>on *lookup*, not on *addition*. It will always find an entity, as
>>>long as "equals" can deal with the current state. That's not the
>>>case with HashSet: The hash code of an object is determined within
>>>the "add" method, and fixed from there on.
>>>
>>>Juergen
>>>      
>>>