persistence@glassfish.java.net

Re: merging as the opposite of refresh?

From: David Van Couvering <david_at_vancouvering.com>
Date: Fri, 20 Apr 2007 16:50:57 -0700

I'm a newbie here too, but perhaps it's a merge if multiple users of a
persistence context modify the same detached entity?

It also might be related to the possibility that somebody else has
modified the same row in the database, and, depending upon the policies
set up, it may end up "merging" what was changed in the db and your
changes. Although in general I think you get an exception saying there
was a conflict and your changes are rolled back.

Again, lots of speculation, I haven't had a chance yet to actually work
with JPA in the wild enough to know what really happens.

David

John O'Conner wrote:
> Forgive the simplistic questions of a JPA newbie:
>
> I have a simple Player entity and have been successful persisting player
> objects to Java DB. However, I'm confused about the merge operation, its
> purpose, and its usage.
>
> In trying to understand merge, I've decided that merge() is like
> refresh() in some ways (or maybe the opposite of refresh). It pushes an
> entity's properties back into the database, overwriting whatever is
> there. I noticed that merge() works on the intended database row only if
> I've set the entity id to match the persisted entity -- no surprise
> there. And all other fields in the row get overwritten with my new
> entity values. The term "merge" does confuse me a little -- no merging
> of anything seems to occur; the operation simply overwrites the db
> record, right?
>
> So two questions:
> Is this comparison to refresh a reasonable comparison?
> Is the merge operation effectively the same as removing an entity and
> persisting it again with the same id?
>
> Thanks,
> John O'Conner
>