Open source reader

Friday, September 22, 2006

*!* Hibernate users, do not skip this *!* The great object Equals and hashCode pattern proposal !

Hi all,

now it is the time to get back on of the nastiest problem of hibernate http://www.hibernate.org/109.html

Looks like there is a valuable solution posted here http://www.hibernate.org/109.746.html !

Does it work ? Yes !
passes successfully the 3 tests listed above in the article:
- "multiple new instances in set"
- "equal to same object from other session"
- "collections intact after saving"
The principals ?
The first time equals or hashCode is called, we check if the
primary key (here getUserId()) is present or not.
If yes: we use it in equals/hashcode
If no: we use a UID (here _uidInEquals) during the entire life of this
instance even when latter on this instance is assigned a primary key.
And there is the sample code too using java.rmi.dgc.VMID !

That's good news for the hibernate community !
Happy O/R'ing !

posted by open source reader at 5:25 PM

5 Comments:

  • If you're going to the trouble of generating and persisting a UUID, why not just use it for the entire lifecycle of the object?

    By Anonymous Anonymous, at 6:14 PM  

  • the uuid is not persisted... that's the point

    By Anonymous Anonymous, at 6:19 PM  

  • This has nothing to do with Hibernate, although you might have first heard of equals/hashCode and equality not based on Heap identity when you started using Hibernate. Every OO language has these constructs and there are many situations when you want to use them.

    Personally, I don't recommend detached objects (never really have) but an extended identity guarantee from the persistence context that spans a whole conversation.

    By Anonymous Christian, at 7:28 PM  

  • This is why I just use UUIDs generated by my app as my PKs. My entities have the same identity from the nanosecond they're created via the constructor.

    Plus, I can generate new entities much faster than a sequence or whatnot in a database. Each app server can be generating on the order of 100+ UUIDs per millisecond (it's 80/ms on my laptop in my tests).

    This simplifies the whole equation 100x, especially since I can see cases where the linked solution won't work too well... Think if you create the new entity (using the UUID for the equals / hashcode for the life of it) then you load the entity via a different session... Now you've got 2 that aren't equal, as far as I can tell. Plus the fact that the UUID generator they're using is pretty slow.

    Oh, and don't let anyone snow you with the "define a natural key" talk. Not every entity will have one, but the real problem is that over the lifespan of an application, which set of fields are, together, a naturally unique key can CHANGE.

    By Anonymous Jason Carreira, at 11:10 PM  

  • Hibernate is like JDBC right?? what are the very special of Hibernate??

    By Anonymous Technical Guy, at 6:28 PM  

Post a Comment

<< Home