[
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.