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

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

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
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>