Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Fri, 30 Apr 2010 20:20:58 -0700 (PDT)
From: JayaPrakash <jpontheweb@sify.com>
To: users@openjpa.apache.org
Message-ID: <1272684058277-4988887.post@n2.nabble.com>
Subject: Order of Insert/Update statement vs @ElementDependent
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_81171_2436541.1272684058277"

------=_Part_81171_2436541.1272684058277
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi All,

        I am into a very tricky situation here on our application. To order
the Inserts/Updates SQLs from parent to child, I have used the property  in
the persistence.xml. This works perfect. 

The actual problem is that I am also using @ElementDependent annotation for
the orphan deletion and this causes the issue. 

Example: 

In a typical scenario of OneToMany bidirectional relationship between A to B
and B to C, I am annotating @ElementDependent in the relationship mapping
from A to B and B to C. In some scenarios, when we want to delete all of the
B records, we nullify the List property inside B and call
entityManager.merge(A). Everything was working fine until we added the
configuration to the persistence.xml as mentioned above. 
The above usecase starting giving errors of late and to analyze the problem
we enabled the SQL trace and monitoring the generated SQLs gave us enough
hint about the problem. As part of update process for A, it is generating
all the Update statements for other objects associated with it and Delete
statements for all the B objects, which is correct. But the strange thing is
that in the of the list of Update statements generated, We could also see
that a bunch of Update statements are generated for C as well (In theory
they should never be because their parents are marked for deletion so these
should also be deleted) and also it is trying to update the C record with
null foreing key value which is actually causing the error. Also another
important point to note here is that the OpenJPA still generates Delete
statements for C objects. But in the order of SQLs the Updates are before
the Deletes. 

What I dont understand is that why is OpenJPA trying to update the children
(C) of an object (B) before deletion when B is marked for deletion. Again,
this started happening only after adding the property in persistence file
for ordering of inserts. 

I kindly request you to help me clearing this problem. I cannot afford to
ignore either order of SQLs or @ElementDependent as both are two eyes of my
application.

Thanks in advance. 
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/Order-of-Insert-Update-statement-vs-ElementDependent-tp4988887p4988887.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

------=_Part_81171_2436541.1272684058277--