Re: [Hibernate] Possible hbm2java generated equals() bug

Matt Hall Fri, 07 Nov 2003 12:15:54 -0800

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

Re: [Hibernate] Possible hbm2java generated equals() bug

Reply via email to