[PEAK] Cascading delete
cogumbreiro at gmail.com
Sun Jul 24 11:20:11 EDT 2005
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)
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
> 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.
More information about the PEAK