Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
- When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. In my experience, the cascade should delete the children first. This solves 99% of the cascade delete issues. It seems to me you'd just have the exact same problem when forward foreign keys (rather than inverse ones as in a one-many) are used. Or do you mean that cascading to a collection should delete the children first, but cascading through a to-one should not? Register now for BEA World 2006 --- See http://www.bea.com/beaworld ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
Hi Abe, On Sep 12, 2006, at 9:21 AM, Abe White wrote: - When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. In my experience, the cascade should delete the children first. This solves 99% of the cascade delete issues. It seems to me you'd just have the exact same problem when forward foreign keys (rather than inverse ones as in a one-many) are used. I think that cascade delete is most commonly used where there is a one-to-possibly-zero relationship (with a [zero or one or many]-to- one on the other side). Thus, the other side has the foreign key, and the side with the cascade delete definition is the side with the existence that doesn't depend on the other side. So deleting the other side first usually solves the timing issues. Or do you mean that cascading to a collection should delete the children first, but cascading through a to-one should not? The side with the cascade delete is not the side with the foreign key that might be violated. So deleting the other side first should always work. Register now for BEA World 2006 --- See http://www.bea.com/ beaworld Thanks for the personal invitation. Craig __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
I think that cascade delete is most commonly used where there is a one-to-possibly-zero relationship (with a [zero or one or many]-to- one on the other side). Thus, the other side has the foreign key, and the side with the cascade delete definition is the side with the existence that doesn't depend on the other side. So deleting the other side first usually solves the timing issues. Does anyone else have an opinion on this? Should we consider the children to be deleted before parent when cascading a delete? I have no problem with that strategy. Register now for BEA World 2006 --- See http://www.bea.com/ beaworld Thanks for the personal invitation. Yeah, I just noticed that they've added that to the outgoing signature. How obnoxious. Supposedly they're working on removing the signature for us. Register now for BEA World 2006 --- See http://www.bea.com/beaworld ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
[ http://issues.apache.org/jira/browse/OPENJPA-39?page=all ] Abe White resolved OPENJPA-39. -- Resolution: Won't Fix Turns out the problem is more complicated than just having a foreign key. The issue is: - OpenJPA's UpdateManager plugin does not reorder SQL. It issues SQL in the same order as the corresponding object-level operations. The SQL-reordering UpdateManager is unique to Kodo. - When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. - Issuing the SQL in that order will violate the FK constraint. OpenJPA is smart enough to detect this and null the children record's FK columns before deleting the parent. - However, the columns in this case are non-nullable, so this strategy doesn't work. So, given that there are no plans to donate Kodo's SQL-reordering UpdateManager, the options are: 1. Use nullable foreign key columns, or 2. Delete the child objects before the parent at the object level. Also if you choose option #1, make sure to get the latest OpenJPA from SVN, as there was a critical problem with nulling the FK columns correctly that is now fixed (9/11/2006). Cascade delete does not work with foreign key constraints - Key: OPENJPA-39 URL: http://issues.apache.org/jira/browse/OPENJPA-39 Project: OpenJPA Issue Type: Bug Components: jpa Environment: Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded Aug 28, 2006) Show » Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded today (Aug 14, 2006) Reporter: Megan Priority: Minor Attachments: testcase.zip Removing a parent object in OneToMany with cascade=CascadeType.ALL raises foreign key constraints exception JpaParent.java @OneToMany(mappedBy=parent, cascade=CascadeType.ALL) private SetJpaChild children = new HashSetJpaChild(); JpaChild.java @ManyToOne(optional=false) @JoinColumn(name=ParentId, nullable=false) private JpaParent parent = null; // This raises the following exception. If foreign key is removed, it works OK (Maybe I have to let OpenJPA know about foreign key constraints) JpaParent parent = em.find(JpaParent.class, 1); em.remove(parent); 2|true|0.9.0-incubating-SNAPSHOT org.apache.openjpa.persistence.RollbackException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:371) at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) 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) Caused by: 0|true|0.9.0-incubating-SNAPSHOT org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at
Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints
Hi Abe, - When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. In my experience, the cascade should delete the children first. This solves 99% of the cascade delete issues. Craig On Sep 11, 2006, at 4:57 PM, Abe White (JIRA) wrote: [ http://issues.apache.org/jira/browse/OPENJPA-39?page=all ] Abe White resolved OPENJPA-39. -- Resolution: Won't Fix Turns out the problem is more complicated than just having a foreign key. The issue is: - OpenJPA's UpdateManager plugin does not reorder SQL. It issues SQL in the same order as the corresponding object-level operations. The SQL-reordering UpdateManager is unique to Kodo. - When you delete a parent object and the operation cascades to children, the object-level operation order is delete parent, then delete children. - Issuing the SQL in that order will violate the FK constraint. OpenJPA is smart enough to detect this and null the children record's FK columns before deleting the parent. - However, the columns in this case are non-nullable, so this strategy doesn't work. So, given that there are no plans to donate Kodo's SQL-reordering UpdateManager, the options are: 1. Use nullable foreign key columns, or 2. Delete the child objects before the parent at the object level. Also if you choose option #1, make sure to get the latest OpenJPA from SVN, as there was a critical problem with nulling the FK columns correctly that is now fixed (9/11/2006). Cascade delete does not work with foreign key constraints - Key: OPENJPA-39 URL: http://issues.apache.org/jira/browse/OPENJPA-39 Project: OpenJPA Issue Type: Bug Components: jpa Environment: Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded Aug 28, 2006) Show » Microsoft SQL Server 2000 Windows XP Java SE 1.5 OpenJPA - source downloaded today (Aug 14, 2006) Reporter: Megan Priority: Minor Attachments: testcase.zip Removing a parent object in OneToMany with cascade=CascadeType.ALL raises foreign key constraints exception JpaParent.java @OneToMany(mappedBy=parent, cascade=CascadeType.ALL) private SetJpaChild children = new HashSetJpaChild(); JpaChild.java @ManyToOne(optional=false) @JoinColumn(name=ParentId, nullable=false) private JpaParent parent = null; // This raises the following exception. If foreign key is removed, it works OK (Maybe I have to let OpenJPA know about foreign key constraints) JpaParent parent = em.find(JpaParent.class, 1); em.remove(parent); 2|true|0.9.0-incubating-SNAPSHOT org.apache.openjpa.persistence.RollbackException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.persistence.EntityManagerImpl.commit (EntityManagerImpl.java:371) at openjpa.test.BaseTestCase.destroyTestCase(BaseTestCase.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod (BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runAfters (BeforeAndAfterRunner.java:65) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected (BeforeAndAfterRunner.java:37) at org.junit.internal.runners.TestMethodRunner.runMethod (TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run (TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod (TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run (TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected (TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected (BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run (TestClassRunner.java:52) 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) Caused by: 0|true|0.9.0-incubating-SNAPSHOT
