Re: [eclipselink-users] Expected behavior for deleting and reinserting a

[Rohit Banga <rohit.banga@xxxxxxxxxx>]

Hi James

Thanks for clarifying this.

I have two questions though:

1. I could not find anything substantial about RepeatableUnitOfWork on the net. Can you point me to the relevant documentation?
2. Also will writechanges() and the subsequent changes be done as part of the same transaction. If the subsequent changes fail then will the changes done by writeChanges() rolled back?

----- Original Message -----
From: jamesssss@xxxxxxxxx
To: eclipselink-users@xxxxxxxxxxx
Sent: Wednesday, June 29, 2011 8:18:38 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: [eclipselink-users] Expected behavior for deleting and reinserting a row with the same unit of work


If by cascade you mean private owned relationships, then no conform will not
conform these as the unit of work does not process these until commit.  You
would need to call delete() on each of these for them to be conformed.

For JPA cascading, these are removed from the unit of work during the remove
call, so they would be conformed.

In general in JPA we no longer use conforming, but flush the changes to the
database before a query execution.  In the native API you can trigger a
UnitOfWork to flush using the writeChanges() API, but will require a
RepeatableWriteUnitOfWork to use this more than once.


Rohit Banga-2 wrote:
> 
> Hi James
> 
> Thanks for your response. I read about Conforming 
> <http://wiki.eclipse.org/Using_Advanced_Unit_of_Work_API_%28ELUG%29> 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
>>>
> 
> 


-----
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-tp31937809p31955401.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users