Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints

2006-09-12 Thread Abe White 


- 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

2006-09-12 Thread Craig L Russell 

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

2006-09-12 Thread Abe White 
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.

Re: [jira] Resolved: (OPENJPA-39) Cascade delete does not work with foreign key constraints

2006-09-11 Thread Craig L Russell 

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