[PEAK] Cascading delete

[Phillip J. Eby]

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, 
though.

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.