POST QUESTIONS ON THE FORUM! COMMENTS HERE SHOULD ADD VALUE TO THE
PAGE!On 26 Feb 2004 19:13, RobJellinghaus wrote:

>On 16 Feb 2004 16:02, hengels wrote:

>>what about using the primary key and fall back to object identity if a
>>pk is not assigned?

>This breaks collections because it changes the object's hashcode once
>you save it.  So you would get:

...

>This *will* print "OOPS!" because newUser's hashcode changed when you
>saved it, so the userSet can no longer find it.

It seems to me that you're assuming a 'wrong' implementation of
hashCode() based on the pk. since we established that the pk may change
(be set) in equal objects hasCode() is not allowed to change if the pk does.

Still you can use pk in equals(). Just compare the pk if and only if
both objects have pk!=0. In case of 0 compare the business key (i.e.
some properties). This is based on the assumption that you will never
change properties that undermine equality once you've saved an object
(set it's pk) i.e. objects that have the same pk are always equal based
on their business key.