yes - for the single object that is correct...buuut for Set's you got something like this:
"Note: Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set. A special case of this prohibition is that it is not permissible for a set to contain itself as an element."
This I read as "unpredictable results when hashcode changes for an elmenet WHILE it is in a set"
The question is: How unpredictable is this ?
One obvious problem is what happens if you add 2 transient objects to your set and they "mutate" in to be equal ?
....but probably more relevant and likely is transient objects that changes hashcode value in e.g. Hash based Sets - that can't be good for the internal hashbuckets ;)
http://www.hibernate.org/109.html for some more links
/max
Matt Hall wrote:
Interesting, seems like there are some issues I didn't consider beyond my current situation. The hashCode() "contract" ( http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#hashCode() ) states that hashCode() doesn't need to return the same value if a field used in the equals changed, so perhaps we will be ok with a basic hashCode() implementation if we can adequately solve the equals() problems. That is unless I'm missing something about 1.a and the way Hibernate handles it's collections while persisting them?
At the very least we should indicate the known failings of the generated methods in some generated Javadoc or something, it can be very confusing to expect to delete one object, and another is mysteriously removed from the list.
Matt
Max Rydahl Andersen wrote:
automatic equals() generation will always be problematic ;)
A problem I haven't found any Good solutoin for:
1. you cannot always test if an object is transient
a. sequence generated keys is first inserted AFTER the insert is performed
b. primitives cannot be null checked (solution: use unsaved-value knowledge)
2. equals influence hashcode and vice versa
Here 1.a. is really hard
+ making a transient object persistent after being inserted into a Collection
will break the hashcode/equals semantics in Collections - NOT GOOD!
Any suggestions for solving the above is much appreciated - even it is some good way to allow easy customization of equals/hashcode generation that consider all the imporant aspects ;)
/max
Matt Hall wrote:
Hey All,
My apologies if this has been covered, but I couldn't find it anywhere in the list or the forums. My concern is that hbm2java generates an equals() method that looks something like:
public boolean equals(Object other) { if ( !(other instanceof MyObject) ) return false; MyObject castOther = (MyObject) other; return new EqualsBuilder() .append(this.getId(), castOther.getId()) .isEquals(); }
Which works fine when comparing two non-transient objects, or a transient and a non-transient (where transient means getId() == null). However, this equals considers all transient objects to be equal which causes serious problems when doing things like list.remove(myObject) when you've got all transients in the list (in fact it will always remove the first element). I have modified the equals to be something like:
public boolean equals(Object other) { if ( !(other instanceof MyObject) ) return false; MyObject castOther = (MyObject) other; if (this.getId() == null && castOther.getId() == null) { return super.equals(other); } else { return new EqualsBuilder() .append(this.getId(), castOther.getId()) .isEquals(); } }
So when two transients are compared it uses the standard Java object compare, otherwise it uses the ids as before.
Does this make sense to people or am I missing something?
Thanks.
Matt
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
