[PEAK] Cascading delete

[Tiago Cogumbreiro]

> >Is calling the event _after_ the super.remove a good thing to do?
> 
> The reason I did that is so that the super method will have a chance to
> make sure that it's a valid thing to remove.  Perhaps the code should first
> get the object's _p_oid and send that as the value of the removed event,
> though.

Do you mean something like:
oid = obj._p_oid
super(WhateverDM, self).remove (obj)
self.removed.send ((obj, oid))

> Note that an object that has just been added may have no oid, yet you still
> may need to break references to it in the foreign key DM to avoid
> "resurrecting" it.  This is why I was having the event send the object,
> rather than the oid.

I am assuming that these type of objects are the ones that are created
and removed in the same transaction. Do they need to be affected by
the cascading delete?

That's another reason why I decided to use "_delete_oids". Objects are
didn't reach the database (aka called _new) are simply discarded.

> 
> Thus, the listening DM's need to check _p_oid directly, and also look for
> just-added (but not flushed) objects that might reference the object directly.
How do I do that, should I checked 'self.dirty'?