Hmmm ...
Alexander Coles wrote:
>
>
> I only include boxed primitive (String) properties + @Embedded
> properties when I write my hashCode() and equals().
> Of course, if you have a property that you know should be unique - a
> natural key - in addition to your surrogate key, you can just use that
> one property as the basis of your hashCode() and equals() methods...
>
>
I thought about getting rid of all the 'junk' that winds up in your
hashCode() and toString() methods. I thought about only using primatives.
But wouldn't this (possibly) cause identification errors? The Hibernate docs
say NOT to use the database id. So if you have an Object with a bunch of int
and String fields, as well as other user-defined fields, like this:
class ParentObject
{
int field1;
int field2;
String field3;
String field4;
MyObject1 field4;
MyObject2 field5;
}
Shouldn't you also stick 'MyObject1' and 'MyObject2' in the hashCode() and
toString() methods, just to be safe (ie. make it easier for Hibernate to
uniquely identify the object by giving it more fields as criteria)?
I don't use Collections in hashCode() and toString(). Too many problems.
Thanks for the reply!
Bob
--
View this message in context:
http://www.nabble.com/Lazy-Exception-again.-WTF--tp18357230s2369p18358403.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
