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().
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 :)
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.