id generation and equals/hashcode

morten · **Joined:** Thu Jul 01, 2004 9:27 am **Posts:** 7

I was reading the Equals and Hashcode wiki page and I was wondering if the following can work:

If you create a POJO object you give it a negative unique id (number). This value is assigned by using a synchronized static class which creates the unique numbers. When the POJO object is stored, the persistance layer will give it a new Id which is a positive unique id (in my case generated by a sequence).

I used this when I wrote my own persistance classes and it worked fine. However, I do not know if it is possible to tell hibernate that negative numbers are not persistant and therefor it should create new ids (I do not know how this code is triggered).

It would be nice to hear some comments on whether or not this could work.

emmanuel · **Posted:** Mon Jul 12, 2004 12:42 pm

Actually we've only implemented the "negative" check for version, not for id.
But it should work fine (you 'll have some synchroinization in your Java code however).

max · **Posted:** Mon Jul 12, 2004 1:42 pm

the problem is (as the wiki page should describe) that if your equals/hashcode depend on a value that changes then you can/will mess up the standard JDK collections! - and your impl does that.

emmanuel · **Posted:** Mon Jul 12, 2004 1:48 pm

damn! I forgot the most important ;-)

morten · **Joined:** Thu Jul 01, 2004 9:27 am **Posts:** 7

Mmmmm, but if I read articles on object equality, most examples use business values in the equals and hashcode values. Lets say for example

Code:

public class Point {
  private int x, y;
  public boolean equals(Object other) {
    if (other == this) return true;
    if (other == null) return false;
    if (getClass() != other.getClass()) return false;
    Point point = (Point)other;
    return (x == point.x && y == point.y);
  }
}

And I have code which moves this Point (assuming there is a moveTo method in the Point) this will also change the base upon which the code determines the equality. This is used in a lot of code. So I do not see the problem in changing the id from a neg number to a pos number affecting the equals method. I probable miss something crucial, please let me know.

(I read the javaworld article: http://www.javaworld.com/javaworld/jw-06-2004/jw-0614-equals.html in which the above structure is recomended.

max · **Posted:** Tue Jul 13, 2004 5:09 am

Go read the spec and try it out your self! ;)

add an object to a hashmap and try to get it again after you have changed it's hashvalue/equals condition !

Alot of code in the world is wrong about this....

...mainly because it is a very suttle bug you discover by accident...

morten · **Joined:** Thu Jul 01, 2004 9:27 am **Posts:** 7

Although you may be right about the hashmap functionality,after reading more documentation (even sugested docs in the hibernate wiki article) it all seems to point to using business values for you hashcode and thus the hascode will change when the value of some properties change. In fact I think this is the whole point of the hashcode.

If this should not be the way it should work, hashcode can not be useful because if you can create a hashcode for an object once without using business data, how can you create a hashcode which returns the same value for two persitant objects retrieved by different sessions ???

christian · **Posted:** Tue Jul 13, 2004 6:07 am

The recommendation is to use a business _key_, which does not change, at least not in situations where it breaks hashCode().

tmckinnon · **Joined:** Mon Nov 03, 2003 6:10 am **Posts:** 75

What about adding another attribute called transientId and modifying the hashcode to use it and the primary key (id) together. The transientId would have no mapping and would exist only in the POJO - specifically to act as a distiguisher for adding these unsaved keyless objects to the set.

I think that would work..