[PEAK] Cascading delete

[Tiago Cogumbreiro]

On 7/22/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> What you want to do is:
>
>      removed = binding.Make(events.Broadcaster)
>
>      def remove(self, ob):
>          super(WhateverDM, self).remove(ob)
>          self.removed.send(ob)
Is calling the event _after_ the super.remove a good thing to do?
If the listening DM's need to know the oid object and our DM derives
from EntityDM its '_p_jar' will be cleared after the super.remove()
call and its oid will not be found, actually _thunk will be called.

>
> Then have your DMs with foreign key references to this DM should subscribe
> methods to the removed event that search for the corresponding child
> objects and remove() them.
>
> *None* of this should be done at the _delete_oids() level, as cascading
> delete is a feature of the domain model, not the storage level.
Choosing _delete_oids() instead of remove() was done more because of
efficiency then semantics. Because one-to-many relations usually tend
to make the cascading delete to remove alot of objects and I thought
it would be more efficient to just send the list of OID's instead of
building up the objects.

Would adding a method removeByOids() make it more correct?

I'm trying to understand why and how things are done instead of making
something that works but will feel more of a hack.

>
> Now, for this to work correctly you are going to want to ensure that the
> foreign key subscribers are always flushed before the primary DM
> flushes.  You may wish to then add something like:
>
>      flushing = binding.Make(events.Broadcaster)
>
>      def flush(self, ob=None):
>          if ob is None: # only send if we're flushing generally
>               self.flushing.send(True)
>          super(WhateverDM, self).flush(ob)
>
> And then subscribe the foreign key DMs to 'flushing' in order to trigger
> flushes of their own.  As long as the foreign key DMs use the primary DM's
> "oidFor()" method to obtain their foreign key values, this will ensure that
> referential integrity is preserved.  (Because "oidFor()" will ensure that
> its argument has been INSERTed in the primary table before it returns the
> foreign key value.)
>
I forgot that one, thanks.