[Zope3-dev] ObjectHub notes: removing objects

[Jim Fulton]

Gary Poster wrote:
> On Sun, 2002-10-20 at 08:56, Steve Alexander wrote:
> 
> 
>>>Is there a practical difference to the *consumers* of these events,
>>>despite the fact that we see one from the outside?  Don't an object
>>>removal and a workflow-related unregister call both require the same
>>>exact processing from all ObjectHub clients?
>>>
>>They are different when you want to delete a Container, an have the 
>>objecthub receive a single ObjectDeleted event, have the objecthub send 
>>on a single HubIdObjectDeleted event, and then have a subscriber to that 
>>event determine transitively the registered objects that are contents of 
>>the deleted container, and inform the objecthub and its subscribers of 
>>the deletion of the objects.
>>
> 
> I don't think that's a good use case--I'll get into why below--but
> actually I did think of another ok reason as to why we might need a
> distinct ObjectRemovedHubEvent: if the object is removed, we need the
> HubEvent's "getObject" method to function differently.
> 
>  * For normal hub events, we can perform getObject either with a
> traverse of the location or an ObjectHub.getObject(hubid).
> 
>  * For unregistered events we can traverse the location.
> 
>  * For Removed hub events we need to get the removed object from the
> Removed object event.

Note that all ObjectEvents are now expected to store the relevent object in
context. I or somebody needs to modify getLocation to to compute
the location from the object if no location was given.

I suggest that hub events should probably store this object as well.


> We could get around this, but the distinction seems reasonably logical
> and practical, and I need to move check things in.  I say, at least as
> far as my checkin is concerned, we keep the removed hub event.
> 
> As to why I don't like the use case: even with the
> ObjectRemovedHubEvent, I don't think we would use it for this.  The
> subscribing of an object in the object hub currently does not require
> the subscribing of all parent folders, nor do I think it should. 
> However, we do need a robust solution to parent deletion. 
> 
> While there are certainly other solutions (like *initially*
> mass-producing boatloads of child object deletion events when a parent
> is deleted...ugh),

Why do you say Ugh?



 > this is a case in which we will probably need some
> sort of subscriber (or arguably even the ObjectHub--this could be
> described as an implication of its contract) that keeps track of the
> names of the parent folders of subscribed objects,

This seems redundant to me. Surely, containers already have the
responsibility to keep track of contained objects, so, given a deleted
container, you should be able to use it to find contained objects that
should be deleted as well.

But. really, there's a much easier approach. Givcen the location->hubid
BTree, it should be possible to trvially find all of the registered objects
under a container by performing a range search. We can and should rely on
paths reflecting containment relationships.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org