| Re: [eclipselink-users] Expected behavior for deleting and reinserting a row with the same unit of work |
|
Hi James Thanks for your response. I read about Conforming on Eclipselink Wiki. I tried using it as well. But somehow I am not able to get it working. I tried with both ReadObjectQuery and ReadAllQuery. In both cases the read query done on the uow returned an object of table T2 which had been deleted by a cascade delete on T1. The wiki mentions "Also, if removed object are not explicitly deleted, they are not conformed." Is a cascade delete treated as an "explicit delete"? Also the wiki entry for conforming a ReadObjectQuery states that "If the database result has been deleted, null is returned." Does this mean the record has been deleted on the database using another client or the entity has been removed from the unit of work on which the readObjectQuery was executed? Thanks Rohit On 6/27/2011 10:25 PM, James Sutherland wrote: 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 --
Thanks and Regards Rohit Banga Member Technical Staff Oracle Server Technologies |