Might I ask why you even need to implement equals for this class? The
default behavior of Object.equals might be just what you need.
Craig
On Mar 16, 2007, at 11:46 AM, Jon Miller wrote:
> 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!
>>
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!
- application/pkcs7-signature attachment: smime.p7s