In my last go-around with our domain model (using entity beans) our equals() implementation only took into account the surrogate primary key value.

This was problematic for clients while creating new objects (which would only compare references), and in moving the code to hibernate I took note of the HiA book's warning that an implementation of hashCode() which involved the surrogate key would break the contract Objects have with collections during a Hibernate cascade-save.

I was also enamored with the idea of using a natural key for equals() and hashCode().

However, I couldn't get over the fact that equals() wouldn't use the surrogate t if it was present. After all, natural keys can change.

At any rate, after going back and forth for a while I came up with an implementation I wanted to throw out there for input [read: criticism] :

I'm thinking that equals() will compare surrogate keys if they exist, natural keys if they don't.

The hashCode() implementation will use only the natural key values in it's algorithm.

If for some reason I have two entities in a collection with the same natural key, but different primary keys, their hash codes will be the same, but that's okay, isn't it? It won't happen often, and their equals() implementations will report them unique.

This way I don't break the contract I have with Set, cascade saves are okay, and I can tell that a persisted entity and it's altered clone are two versions of the same row.

Thoughts?

I avoid the problem by having the original objects hashCode stored to the database. This saves me a whole lot of pain. Fortunately I'm in a position to make this decision. Companies with an existing database will not be so kind as to include a hashCode field.

I do think its kinda wastefull storing hashCode but it suites my ease-of-use scenarios.

This is not safe since your equals results could change between before and after hibernate.save() has been done.

Remember that the "natural key" used in equals has to be unique during the JVM instance life time (not the whole life of the application)

aarh - not completly true, is it?

It only need to be stable while it is inside something (like a Collection or Map) that expects it to be stable.

I guess my reasoning on that is that my hashCode implementation won't change (during a cascade-save for instance). My equals() implementation will change, but I can guarantee that it won't break the transitive nature of hashCode() or equals().. So while I'm technically breaking the contract, I'm not doing so in spirit.

I dunno. Buy that?

I am consider to use ArraySet or LinkedSet to bypass the hashCode() issue.

Any comments?

yes - how ? ;)

The root problem:
a) cal hashCode() using your PK
b) add your new object to a HashSet
c) call session.save() which assign value to your PK
d) HashSet lost your object because your hashCode() is changed

My solution is to use ArraySet or LinkedSet which never call to hashCode(). The only problem of ArraySet/LInkedSet is slower because it do not use hashCode().

The ArraySet should look like this:
http://cvs.sourceforge.net/viewcvs.py/t ... &view=auto

I want to hear some comments before I do implement this solution to my program....

NB: Anyone know where is the best ArrySet or LinkedSet?

just a perhaps stupid question ...

but why not use business-fields for 'hashCode'? If the pk is generated i think it's not really the best solution for 'hashCode'-calculation ... and if the pk is assigned by application, it's set before your save/update-call and therefore no problem ...

or do i miss something?

gtx
curo

the only issue with using a specific implementation of a Collection is that Hibernate won't honor that as it needs to wrap the collection with a hibernate managed collection.


Regarding businesskeys - then you are correct that it is probably better, but the businesskey just need to be assigned/set on the object (and not change) before adding it to an collection.

[quote="max"]the only issue with using a specific implementation of a Collection is that Hibernate won't honor that as it needs to wrap the collection with a hibernate managed collection.

Let's use this class as am example:

class C{
private Set items= new ArraySet();
public getItems() {
return items;
}
...
}
Do you mean that even c.getItems return a empty Set, Hibernate still create a Set proxy using another HashSet()? I think Hibernate will only generate Set proxy when lazy="true"?



Are you talking about the wrapper net.sf.hibernate.collection.Set always use HashSet()?
public void beforeInitialize(CollectionPersister persister) {
this.set = persister.hasOrdering() ?
LinkedHashCollectionHelper.createLinkedHashSet() :
new HashSet();
}

i'm talking that to record which items has been removed/deleted from a collection we need to wrap it.

As per the docs - do not assume anything about these Collection/List/Set other than they conform to the Collection API.

Thanks for your comments. But I will take the risk and try it in my new project.
If ArrayList really fail, I will hardcode all hashCode() to return 1. :(

After re-read TimTwe's message, instead of saving the hashCode into database, maybe I can save the record create date-time into database? It's much eaiser to ask our DBA to add a CREATE_DATE column. I don't think my DBA will allow me to add HASH_CODE column to database :)
Does anyone have try to use the record create date-time for equal() and hashCode?