[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Pre-existing managed entity instances in the persistence context: pre-existing on disk? Or...?
|
No you won't. Before merging the object is read from the db.
If it's not there then insert else update.
All I was trying to say is what the target entity is.
On 7/26/2013 12:52 AM, Laird Nelson wrote:
On Thu, Jul 25, 2013 at 1:02 PM, Andrei Ilitchev
<andrei.ilitchev@xxxxxxxxxx <mailto:andrei.ilitchev@xxxxxxxxxx>> wrote:
Merge searches persistence context for entity with the same id as
the detached being merged to put merge result into it (say, it has
been read before through the same entity manager and em.clear hasn't
been called).
If none found then merged result placed into a new entity.
OK, so I *will* get a primary key duplication error *by spec*?
Recall the code is:
final SomeEntity x = new SomeEntity();
x.setID(6); // set the @Id -- the persistent identity
//
// Assumption: x is now "detached"; it is not "new"
// Please correct this assumption if it is false.
//
em.clear(); // empty persistence context
// 1
final SomeEntity xPrime = em.merge(x); // 2
em.flush(); // 3 -- Duplicate primary key error? If not, why not?
So I will get a primary key duplication error at point 3 *by spec*, yes?
Because at point 2 a new entity with the same persistent identity was
introduced into the persistence context?
Many, many people are laboring under the delusion that everything will
be just fine. They think that at point 3 the spec requires the JPA
provider to conduct a search for the right row on disk and to UPDATE it
if one is found. You are saying that an INSERT might very well
happen--and fail, in this case. Right?
Best,
Laird
--
http://about.me/lairdnelson
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
