Skip to main content

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

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

Back to the top