You should never change the primary key value of an object.
Instead delete the old object, and create a new one with the new primary
key.
If general when executing a query in a unit of work you need to set the
query to conform, if you want it to consider the unit of work's in-memory
changes such as deleted objects. You can also flush EntityManager if using
JPA.
Rohit Banga-2 wrote:
Hi All
I have a usecase where I may need to modify the primary key value of a
table.
For achieving this I create a unit of work, read the entity (E) from the
database, register E with UOW and delete E from the UOW. I then create a
new entity E1. I populate all the required direct to field mappings and
register E1 with UOW. When I commit the UOW, the new row appears on the
database with the modified primary key column value.
This works fine for the single table scenario.
But assume that E spans across tables T1 and T2. T1 has a one-to-one
mapping to table T2. Also delete is set to cascade from T1 to T2. So
when I delete an entity constructed from T1, indeed the corresponding
row in T2 is deleted.
However in the above scenario since I am working with the same unit of
work I am observing some weird behavior. When I delete E from UOW, I
expect that the corresponding rows in T2 should automatically be
considered as deleted. So when I create E1, I try to insert the
corresponding rows (entities) of T2 again and link them to E1. But
before I do this insert for T2 entities I do a check on whether the
entity already exists in T2 or not. As it turns out, I am able to read
the T2 entity before the insert (I am doing the read using the same
UOW). This violates the invariant that I established earlier -
corresponding entities of T2 should be deleted when E is deleted from UOW.
Am I missing something about object identities? Is this expected behavior?
For my usecase, the primary key columns that have to be modified are
from T1 only. So I think I will be better off creating a
DeleteObjectQuery that deletes the record from T1 alone and reinserts it
into T1 with the modified primary key value. The delete would not
cascade to T2 in such a scenario (I think this should be possible with a
DeleteObjectQuery). This would of course require delayed processing of
foreign key constraints on the database. Can someone please suggest
whether this should be the way to go?
--
Thanks and Regards
Rohit Banga
Member Technical Staff
Oracle Server Technologies
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
Blog: http://java-persistence-performance.blogspot.com/ Java Persistence
Performance