Hello all,
The specification mandates that the merge call will always return a copy of the value passed to the merge operation. In the case of a new object the specification requires that TopLink and all persistence providers return a copy of the new object on a merge operation.
--Gordon
-----Original Message-----
From: Wonseok Kim [mailto:guruwons_at_gmail.com]
Sent: Tuesday, January 16, 2007 11:15 AM
To: persistence_at_glassfish.dev.java.net
Subject: Re: Why does EntityManager.merge() return a reference and persist() doesn't?
Hi Jon,
In the same Persistence Context(PC) it should maintain one managed object for the same PK so the same object can be returned by em.find() or query. If the object passed in merge() is detached one, there may be already the corresponding managed one in the PC, so the managed one is returned.
But for a new object merge() does like persist() and two operations could behave a little different depending on implementations. TopLink doesn't use the new object which is passed in merge() directly, it makes a new managed copy and return it internally. I don't know merge() should always return a new managed copy for a new object, but TopLink is implemented in that way.
Cheers,
-Wonseok
On 1/13/07, Jon Miller <jemiller_at_uchicago.edu> wrote:
I'm starting to get confused here. Why does merge() return a reference that
is in the persistence context? Why doesn't it just use the reference that
you pass in? I don't understand why the behavior is different for merge()
than for persist().
I've been using merge() for both adding and updating objects. I'm thinking
that maybe I should be using persist() for adding new objects and only use
merge() for existing objects.
Jon