hi marina,
assuming all the relationships are loaded in the detached object, which is true as far as i can tell, IMHO, A.equals(B) should work under any condition, different JVMs, EMs, or transactions. if it doesn't, it puts a serious monkey wrench in the usability of JP.
for example, i have a Set of entity objects. i put A and B in the set. i'd expect that they are the same, and there should only be one of that object in the Set per set semantics. however, this won't be the case.
or, what if i want to use my entity objects as a keys in a hashtable?
note that the javadocs for AbstractList.equals() says that for two lists to be equal, they
1. need to be of type List
2. need to have the same # of elements
3. for all elements, A.get(n).equals(B.get(n))
(or something close to that).
so, it shouldn't matter what implementation of List is there in the detached object B, as long as A has a List impl that extends AbstractList (which it does in my case), and it obeys those semantics above ... which seems like a reasonable assumption. no?
thanks.
Marina Vatkina <Marina.Vatkina_at_Sun.COM> wrote: 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?
> Loosen up...
> Download and play hundreds of games for free
> on Yahoo! Games.
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.