Issue Details (XML | Word | Printable)

Key: NUCCORE-855
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Core

Simple SCO container wrappers could delay processing of cascade-delete until flush/commit

Created: 16/May/12 01:03 PM   Updated: 30/May/12 03:09 PM
Component/s: Persistence
Affects Version/s: None
Fix Version/s: None


 Description  « Hide
The "simple" SCO wrappers for Collection/Map fields now handle cascade delete. They perform the delete immediately. While this complies with the JDO spec, it would be nice to register all updates perhaps with RelationshipManager and run that at flush to handle such deletes.

An example, if we have a 1-N bidir and we want to move an element from one owner to another. We remove the element from the old owner, and then add it to the new owner. The only problem is that the container has "dependent-field" specified and the remove() will cause it to be deleted before it can be added to the new owner. The proposed new mode of RelationshipManager will need to check for triggering of cascade-delete and then check if the owner of the element has since been changed and not null, this would then not cause it to be deleted.

Sort Order: Ascending order - Click to sort in descending order
Chris Colman added a comment - 17/May/12 05:55 AM
This would be a great improvement. Currently we have to specify non dependent relationships for relationships that would otherwise be dependent because, if dependent, we can't change their owner - which we need to be able to do.

Andy Jefferson added a comment - 30/May/12 03:09 PM
Notes for implementation :
1. This is only aimed at the "simple" SCO wrappers currently. That is for all datastores except RDBMS and GAE. These don't have a backing store so have their own wrappers.
2. Need to cater for all possible routes for swapping elements. Namely if we have owner class A and element class B, and "a1" has element "b1" which we want to move to "a2". So two possible ways to swap :-

a2.getElements().add(b1);
a1.getElements().remove(b1);

a1.getElements().remove(b1);
a2.getElements().add(b1);

Any mechanism has to support both.


Once this is done then extend to SCO wrappers with backing store.