RE: [eclipselink-dev] Cascade Deletes through ManyToMany

[James Sutherland <JAMES.SUTHERLAND@xxxxxxxxxx>]

No, this is wrong, and was attempted before and broke as much as it fixes, including most inserts.

For delete to be correct they MUST be processed the inverse of how we process inserts.

On inserts, inserts into the m-m join table are deferred until the end of the commit.  So the inverse must occur, deletes from the m-m join table must be processed at the start of the deletion process.
We just need an initial preDelete loop of all of the delete objects, before the main deletion loop.  We also need to be able to perform shallow delete to resolve bidirectional relationships, but I think this was already added.

For privately owned relationships this means that we must compute all objects that will be delete before the deletion process begins.

We also have the privately owned removal issue that also needs to be fixed, currently we delete objects removed from privately owned relationships during the update, but these must be deferred to the deletion phase.



-----Original Message-----
From: Gordon Yorke 
Sent: Monday, February 16, 2009 11:41 AM
To: James Sutherland
Cc: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Cascade Deletes through ManyToMany

One of the outstanding cascade delete support issues is with ManyToMany
relationships like Employee-> Project.
The delete in this case fails when constraints are present because the
Project is deleted before Employee.  We attempt to delete in this order
because there is no dependency calculated on ManyToMany relationships so
EclipseLink will use the reverse alphabetically order of the classes and
delete project first.  Deleting Project first results in constraint
violations on the relationship table.

This issue exists beyond cascade delete as even if the user deleted the
two object manually the constraint violation would still occur.

The easiest solution is to simply report the dependency on writable
ManyToMany mappings but this may break previous applications that were
dependent on the pseudo random ordering that EclipseLink used previously
(some of our testing breaks).

Special code could be added to update the collection on cascade remove
but there's no guarantee that the update may not be optimized out at
some later date and it does not solve this issue when cascade delete is
not used or JPA is not used.

I recommend we update the dependency.

--Gordon
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev