[PEAK] Cascading delete
Phillip J. Eby
pje at telecommunity.com
Sun Jul 24 11:41:03 EDT 2005
At 03:20 PM 7/24/2005 +0000, Tiago Cogumbreiro wrote:
>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?
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,
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.
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.
>Would adding a method removeByOids() make it more correct?
No; see above for why. You can't do this with just the oids, since a
newly-created object may not *have* an oid.
Arguably this is a design flaw, though. If I were writing this fresh
today, I would make add() ensure the object had an oid assigned, but the
current oidFor() mechanism wouldn't work for that; it's a hook to ensure
referential integrity. add() would need to call some sort of "assignOid"
thing that *only* computed the oid value and set it in the object.
Now that I have a few more years experience than when I first created the
data_managers framework, there are a lot of things I'd do differently, but
properly dealing with domain OIDs (primary keys) is one of the biggest.
More information about the PEAK