Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <15636961.1180639815842.JavaMail.jira@brutus>
Date: Thu, 31 May 2007 12:30:15 -0700 (PDT)
From: "Reece Garrett (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Commented: (OPENJPA-235) SQL reordering to avoid
 non-nullable foreign key constraint violations
In-Reply-To: <16358846.1178303115756.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500460 ] 

Reece Garrett commented on OPENJPA-235:
---------------------------------------

Gokhan,

Thank you for the test cases. The first test case ( testMergeAttached ) passes but the other case ( testMergeDetached ) fails before it even gets to my code. I see what you're trying to do and my patch should handle it. I'm sorry I don't have time to tell you why the error occurs but I suspect it is a problem with your annotations. Here is the error testMergeDetached generates:

<0.0.0 nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Encountered new object "org.apache.openjpa.persistence.merge.model.EntityB@1450f1f" in persistent field "org.apache.openjpa.persistence.merge.model.EntityC.parent" of managed object "org.apache.openjpa.persistence.merge.model.EntityC@1a722ef" during attach.  However, this field does not allow cascade attach.  You cannot attach a reference to a new object without cascading.
FailedObject: org.apache.openjpa.persistence.merge.model.EntityB@1450f1f
	at org.apache.openjpa.kernel.AttachStrategy.getReference(AttachStrategy.java:276)
	at org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:193)
	at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:134)
	at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:239)
	at org.apache.openjpa.kernel.AttachStrategy.attachCollection(AttachStrategy.java:330)
	at org.apache.openjpa.kernel.AttachStrategy.replaceCollection(AttachStrategy.java:298)
	at org.apache.openjpa.kernel.AttachStrategy.attachField(AttachStrategy.java:220)
	at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:134)
	at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:239)
	at org.apache.openjpa.kernel.AttachStrategy.attachCollection(AttachStrategy.java:330)
	at org.apache.openjpa.kernel.DetachedStateManager.attach(DetachedStateManager.java:250)
	at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:239)
	at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:100)
	at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3176)
	at org.apache.openjpa.kernel.DelegatingBroker.attach(DelegatingBroker.java:1147)
	at org.apache.openjpa.persistence.EntityManagerImpl.merge(EntityManagerImpl.java:665)
	at org.piercecountywa.personnel.openjpa.TestMultigenOneToManyMerge.testMergeDetached(TestMultigenOneToManyMerge.java:108)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at junit.framework.TestCase.runTest(TestCase.java:164)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:228)
	at junit.framework.TestSuite.run(TestSuite.java:223)
	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Again, the good news is the first test case runs great and what you're trying to do in the second test should work great too. If you can figure out what the issue is on that second test please post it.

> SQL reordering to avoid non-nullable foreign key constraint violations
> ----------------------------------------------------------------------
>
>                 Key: OPENJPA-235
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-235
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>            Reporter: Reece Garrett
>            Assignee: Patrick Linskey
>             Fix For: 0.9.8
>
>         Attachments: merge-detached.patch, merge-multigen-collection-testcase.zip, openjpa-235-test.jar, openjpa-235-test1.jar, sqlreorder.patch, sqlReorder2.patch
>
>
> OpenJPA does not do any SQL statement re-ordering in order to resolve foreign key constraints. Instead, objects are always inserted in the order in which the user persists the instances.  When you persist in an order that would violate foreign key constraints, OpenJPA attempts to insert null and then update the foreign key value in a separate statement. If you use non-nullable constraints, though, you must persist your objects in the correct order.
> This improvement re-orders SQL statements as follows:
> 1. First, all insert statements execute. Inserts which have foreign keys with non-nullable constraints execute AFTER the foreign keys which they depend on have been inserted since no deferred update is possible.
> 2. Next, all update statements execute. No reordering is necessary.
> 3.  Finally, all delete statements execute. Like inserts, deletes execute in an order which does not violate non-nullable foreign key constraints.
> If a circular foreign key reference is found during the re-ordering process then re-ordering halts and the remaining unordered statements are left as is. There is nothing that can be done about the circular reference (other than fixing the schema) and the resulting SQL statements will not succeed.
> The net effect is that users do not need to worry about the persistence order of their objects regardless of non-nullable foreign key constraints. The only class modified was org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a patch which includes my modifications to OperationOrderUpdateManager and test cases. The test cases I have provided fail on the current trunk but pass with my modifications. I have also verified that I did not break anything by using maven to run all test cases with my modifications in place.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.