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

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

Hi!

I think I know another safe solution... which has its own drawbacks, of=20
course:

Given I want to use native db sequences and I use DAOs in my app-design,=20
I could disallow access to all domain objects' (objects to be=20
persisted) constructors and insert a 'newInstance' method for each=20
domain object in a/the DAO. This 'newInstance' method would call the=20
constructor, then access the native db sequence for the next value,=20
change the id in the newly created instance, and return that instance.=20
As far as I see it, this should "do it".

Drawbacks:=20
=2D You can no longer create new domain object instances easily outside=20
your app (/appserver), say in a remote Client accessing your EJB-app.
=2D Each and every domain object instance now needs one additional db=20
access at instantiation time.
=2D There will be "holes" in your database tables when you look at the id=20
sequences when you create a domain object instance that will be dropped=20
without persisting it.
=2D I'm not sure if the special m:n is handled correctly....
=2D Using autoincrement columns with this approach might not be as easy as=
=20
using sequences.

Have I missed something? Opinions?


Regards,

Timo

Am Freitag, 1. August 2003 19:51 schrieb Colin Sampaleanu:
> 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=3D909482&forum_id=3D1286
>38
>
> 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=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 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-develope
>r