This is something that I've been wondering about. It certainly would be a
lot easier to just use the id field. However, as far as I know this can
cause problems with sets when you try to add two objects to a set before
they have been persisted (at this point both ids would be null so one would
be replaced by the other). As long as you never do that, I guess it isn't a
problem. I read a Hibernate document awhile back which recommended against
using id when implementing equals() for this reason. Comparing entire
collections in equals() seems a bit excessive though.
Jon
----- Original Message -----
From: "Craig L Russell" <Craig.Russell_at_Sun.COM>
To: <persistence_at_glassfish.dev.java.net>
Sent: Friday, March 16, 2007 1:27 PM
Subject: Re: calling equals() on a detached object
> 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 <jemiller_at_uchicago.edu>/* 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? <http://us.rd.yahoo.com/evt=49935/*http:// games.yahoo.com>
>>> Loosen up...
>>> Download and play hundreds of games for free
>>> <http://us.rd.yahoo.com/evt=49935/*http://games.yahoo.com> 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!
>
>