Cascading delete needs to be slightly smarter

[pobrien]

The cascading delete system needs to be improved to support a number of things:

• Edge cases where a cascading delete is blocked by a reference from some entity that is already known to be deleted during the same transaction.
• Support for EntityList?, EntitySet?, and custom entity-storing fields.
• New REMOVE option for on_delete specs, which implies that if entity A has an EntityList? field that contains entity B, and entity B is deleted, entity B should be removed from the list on entity A.

Also covered in this ticket is allowing direct mutation of EntityList? and EntitySet? field values in a transaction, while making them immutable when attached to entities and views.

ALSO covered are allow_unassigned and allow_duplicates for EntityList?, and allow_empty for EntityList? and EntitySet?.

[mscott]

One failing test case that is still commented out as of this writing can be found at: source:tags/releases/Schevo-3.0/tests/test_on_delete.py#L198

This ticket could be rewritten to describe the smarter cascade delete system that we envision -- the one that supports RESTRICT/CASCADE/UNASSIGN/REMOVE options and also supports EntityList? fields and the like.

[mscott]

r3211 fixes edge cases where cascade delete didn't work right because of a sneaky RESTRICT. All cascade delete tests are uncommented, and all pass.

[mscott]

Implementation and docs complete as of r3218.

We'll need to figure out how to handle UNASSIGN with EntityList? and EntitySet? before we do a final review and merge.

[mscott]

Ready for review at r3224

[mscott]

r3230 changes behavior to ignore allow_empty and instead enforce min_size and max_size constraints.

[mscott]

pobrien added an EntitySetSet? field type.

This branch has been mutually reviewed and is scheduled for merge to trunk on 2007-05-24.

[mscott]

merged at r3233