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!
- application/pkcs7-signature attachment: smime.p7s