| CascadeType=ALL does not result in ON DELETE CASCADE? [message #389729] |
Wed, 24 June 2009 13:25  |
 Frank Sauer
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
I have a situation where CascadeType=ALL and even @PrivateOwned does not
result in child object being deleted. IN fact deletion results in FK
constraint violations... Here are the JPA annotations:
@OneToMany(cascade = CascadeType.ALL , fetch = FetchType.EAGER)
@JoinTable(name = "PLimitSlice_PossibleValue", joinColumns = {
@JoinColumn(name = "PLIMITSLICE_ID", referencedColumnName = "ID") },
inverseJoinColumns = @JoinColumn(name = "POSSIBLEVALUE_ID",
referencedColumnName = "ID"))
@PrivateOwned
private List<PossibleValue> possibleLimitValues = new
ArrayList<PossibleValue>();
and the resulting DB2MainFrame DDL below- which prevents me from deleting
anything... This occurs with most if not all of our relations. What do I
have to do to make either the FK constraint go away or get cascading
deletes going?
Thanks,
Frank
-- Version: V5R4M0 060210
-- Generated on: 06/24/09 08:17:50
-- Relational Database: D100585M
-- Standards Option: DB2 UDB iSeries
CREATE TABLE PDE_REPO2.PLIMITSLICE_POSSIBLEVALUE (
PLIMITSLICE_ID FOR COLUMN PLIMI00001 VARCHAR(255) CCSID 37 NOT NULL ,
POSSIBLEVALUE_ID FOR COLUMN POSSI00001 VARCHAR(255) CCSID 37 NOT NULL ,
CONSTRAINT PDE_REPO2.Q_PDE_REPO2_PLIMI00001_PLIMI00001_00001 PRIMARY KEY(
PLIMITSLICE_ID , POSSIBLEVALUE_ID ) )
;
ALTER TABLE PDE_REPO2.PLIMITSLICE_POSSIBLEVALUE
ADD CONSTRAINT PDE_REPO2.FK_PLIMITSLICE_POSSIBLEVALUE_PLIMITSLICE_ID
FOREIGN KEY( PLIMITSLICE_ID )
REFERENCES PDE_REPO2.PLIMITSLICE ( ID )
ON DELETE NO ACTION
ON UPDATE NO ACTION ;
ALTER TABLE PDE_REPO2.PLIMITSLICE_POSSIBLEVALUE
ADD CONSTRAINT PDE_REPO2.FK_PLIMITSLICE_POSSIBLEVALUE_POSSIBLEVALUE_ID
FOREIGN KEY( POSSIBLEVALUE_ID )
REFERENCES PDE_REPO2.POSSIBLEVALUE ( ID )
ON DELETE NO ACTION
ON UPDATE NO ACTION ;
|
|
|
|
|
|
| Re: CascadeType=ALL does not result in ON DELETE CASCADE? [message #389740 is a reply to message #389733] |
Thu, 25 June 2009 13:55  |
|
I believe this issue was fixed in the EclipseLink 2.0 stream, but has not
yet been backported to the 1.1 stream. You can try upgrading to the
latest 2.0 milestone build.
The issue is that because there is no direct constraint between the parent
and child, the EclipseLink deletion order can attempt to delete the child
object first, instead of the parent.
To workaround the issue you could,
- Use the addConstraintDependecy() API in ClassDescriptor to influence the
delete order to delete the parent object first.
- Mark the relationship as @PrivateOwned, but not as CascadeType.ALL
(don't cascade remove).
- Remove the constraint from your table, or add a cascade delete to the
constraint.
---
James
http://www.nabble.com/EclipseLink---Users-f26658.html
James : Wiki : Book : Blog : Twitter
|
|
|
Powered by
FUDForum. Page generated in 0.03598 seconds
] 
Search
Help
Register
Login
Home
