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

[Timo V. <sic...@gm...>]

Hi!

It might be a good idea to discuss these issues on the hibernate=20
forums/mailing lists. I could imagine, there are others who had these=20
problems before.


Regards,

Timo

Am Dienstag, 29. Juli 2003 17:18 schrieb Colin Sampaleanu:
> j=FCrgen h=F6ller [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=20
> 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_0723
> >03_01/01 _______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-develop
> >er
>
> -------------------------------------------------------
> 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-develope
>r