Here's what it says on the Hibernate site about implementing equals() in
case anyone is interested.
http://hibernate.org/109.html
Jon
----- Original Message -----
From: "Craig L Russell" <Craig.Russell_at_Sun.COM>
To: <persistence_at_glassfish.dev.java.net>
Sent: Friday, March 16, 2007 5:16 PM
Subject: Re: calling equals() on a detached object
> Hi Jeff,
>
> On Mar 16, 2007, at 12:02 PM, jeff wrote:
>
>> thanks craig,
>>
>> actually, the same thought occurred to me. the logic in equals()
>> really shouldn't be doing any more than checking that the entity's
>> ID's are equal. in other words, the check for equality in the
>> database should be reflected in equals().
>
> This will really serve you well.
>>
>> that being said, i still don't see a reason why my overly complex
>> equals() operation should fail ... even if it's a contrived example :)
>
> The other reason that it's not advised to get fancy with equals is
> because if you use a field that is in a relationship, you end up in a
> recursion because A checks for equality for all its B's and B checks
> for equality of its A. And then equals becomes an object graph
> equality which is not often what you want.
>
> Craig
>>
>> Craig L Russell <Craig.Russell_at_Sun.COM> wrote:
>> Hi Jeff,
>>
>> I think I'd recommend you think about what the purpose of equals()
>> is. In my experience, equals() is most productively used where there
>> is some intrinsic notion of identity, and not a field-by-field
>> equality comparison. For persistent instances, this is the id field
>> or property.
>>
>> So I'd suggest making your equals() method simply compare the id
>> field or property and be done with it. Your current implementation
>> that compares more than just the id will result in unexpected
>> behavior.
>>
>> For example, unexpected behavior includes being able to add to a Set
>> two instances that have the same id field but differ in other fields.
>> This is probably not what you want, especially for a persistent Set.
>>
>> Craig
>>
>> On Mar 16, 2007, at 11:10 AM, Gordon Yorke wrote:
>>
>> > Your equals result should still work as long as you delegate to the
>> > Set's equal() method for comparison. TopLink replacing the
>> > implementation should have no effect on equals(). If the two sets
>> > contain the same objects, and those objects implement equals()
>> > correctly but the sets are not equal then please file a bug.
>> > --Gordon
>> >
>> > -----Original Message-----
>> > From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On
>> > Behalf Of
>> > Marina Vatkina
>> > Sent: Friday, March 16, 2007 1:52 PM
>> > To: persistence_at_glassfish.dev.java.net
>> > Subject: Re: calling equals() on a detached object
>> >
>> >
>> > A == B won't work even if you do it in 2 different EMs ;). Note
>> > that TopLink
>> > replaces internally the relationship field marked for LAZY loading
>> > (explicitly
>> > or implicitly) with its own collection implementation which can
>> > affect your
>> > equals() result.
>> >
>> > regards,
>> > -marina
>> >
>> > jeff wrote:
>> >> hi jon thanks,
>> >>
>> >> hmmm. really?
>> >>
>> >> in a single JVM scenario, within a given transaction, i think what
>> >> you
>> >> say is right.
>> >>
>> >> however, are you saying that in one JVM i persist object A, then in
>> >> another JVM i fetch the same object ID, A == B will be true? i
>> >> don't see
>> >> how that can be the case.
>> >>
>> >> note that in my case, it's the same JVM, but the persist and fetch
>> >> are
>> >> done in different transactions. the equals() test fails.
>> >>
>> >> sure i can post some code ... but before i bother, i'll wait for a
>> >> response to make sure i am making any sense here.
>> >>
>> >> */Jon Miller /* wrote:
>> >>
>> >> It would probably help if you posted some code. As far as I
>> >> know, A
>> >> and B in
>> >> what you described below should not only be equal objects, they
>> >> should be
>> >> the exact same object. i.e. A == B should return true.
>> >>
>> >> Jon
>> >>
>> >> ----- Original Message -----
>> >> From: "jeff"
>> >> To:
>> >> Sent: Friday, March 16, 2007 11:10 AM
>> >> Subject: Re: calling equals() on a detached object
>> >>
>> >>
>> >>> hi jon,
>> >>>
>> >>> yes :) i did, and i've tested my impl of equals and it works in
>> >> the simple
>> >>> POJO case.
>> >>>
>> >>> thanks.
>> >>>
>> >>> Jon Miller wrote: Did you override equals()?
>> >>>
>> >>> Jon
>> >>>
>> >>> ----- Original Message -----
>> >>> From: "jeff"
>> >>> To:
>> >>>
>> >>> Sent: Wednesday, March 14, 2007 7:25 PM
>> >>> Subject: calling equals() on a detached object
>> >>>
>> >>>
>> >>>> i'd like to be able to do this ...
>> >>>>
>> >>>> 1. create object A
>> >>>> 2. persist object A
>> >>>> 3. find() object B based on A's ID (they should be "equal()"
>> >>>> 4. detach B
>> >>>> 3. call A.equals(B) and get a true result
>> >>>>
>> >>>> i've done this, and it does not work. as far as i can tell w/ the
>> >>>> debugger, they are equal. the problem appears to be when a field
>> >> of type
>> >>>> Set is compared.
>> >>>>
>> >>>> when i poke into B, and try to look into the Set, i have to bury
>> >> way down
>> >>>> in some toplink objects before i find the right values for the
>> >> set, but
>> >>>> they ARE in there somewhere.
>> >>>>
>> >>>> also, to make sure B is all fetched, i called B.equals(B) before
>> >>>> detaching, which should load everything i care about i think. if
>> >> there's
>> >>>> a
>> >>>> better way to do this, i'd like to hear it :)
>> >>>>
>> >>>> when i call toString() on the Set inside of A and B, the
>> format is
>> >>>> slightly different but it does contain the same data: for
>> >> example ...
>> >>>>
>> >>>> A's set: [zipCodes=[11111, 22222, 33333]]
>> >>>> B's set: {{[zipCodes=[11111, 22222, 33333]]}}
>> >>>>
>> >>>> so i guess this means the same data is there, but i don't
>> >> understand why
>> >>>> "equals" is failing.
>> >>>>
>> >>>> any ideas?
>> >>>> thanks.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------
>> >>>> No need to miss a message. Get email on-the-go
>> >>>> with Yahoo! Mail for Mobile. Get started.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ---------------------------------
>> >>> Expecting? Get great news right away with email Auto-Check.
>> >>> Try the Yahoo! Mail Beta.
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> ---
>> >> Bored stiff?
>> >> games.yahoo.com>
>> >> Loosen up...
>> >> Download and play hundreds of games for free
>> >> on
>> >> Yahoo! Games.
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell_at_sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>> Food fight? Enjoy some healthy debate
>> in the Yahoo! Answers Food & Drink Q&A.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell_at_sun.com
> P.S. A good JDO? O, Gasp!
>
>