Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Expected behavior for deleting and reinserting a row with the same unit of work

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 
-- 
View this message in context: http://old.nabble.com/Expected-behavior-for-deleting-and-reinserting-a-row-with-the-same-unit-of-work-tp31937809p31939521.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top