[Zope3-dev] ObjectHub notes: removing objects

[Steve Alexander]

Hi Kevin, Gary,

Nice answer Gary. I'd like to make a few comments though.


>>I ask because it strikes me that, first of all, you don't want objects
>>that aren't registered in the system at all, in some respects - what
>>happens if you add an object, don't register it, then add a registered
>>object underneath/in that?  Surely, that means the name/location of the
>>object can change by moving it's parent without generating an event,
>>which would be bad(tm).
> 
> 
> First, the event system is not the object hub: the object hub is a
> client of the event system.  By which I mean, yes, *every* object should
> be hooked into the event system, launching ObjectEvents (see
> Zope.Event.ObjectEvent).

When you consider the ZODB, persistent objects are fairly fine-grained.

I suggest that not every object should be hooked into the event system. 
Rather, every "significant" content object is hooked into the event 
system. What makes a "significant content object" is related to Jim's 
recent discussion question of "what is a content type?".


> HubEvents are another sort of events that
> ObjectEvents can cause an ObjectHub launch, only if the pertinent
> objects are in the given object hub.  Not all objects will be in an
> object hub, and there may in fact be multiple object hubs (if you like
> headaches ;-)
> 
> You do touch on an important point though: how *do* we keep the event
> service chugging?
> 
> this part of the mechanism has two proposed solutions, so far.  There is
> the "don't do anything without getting an event-sending adapter around
> it first" approach, which would solve your concern because it would not
> be the folder that sent the events. This or some variation will probably
> happen since it is what I heard last from Jim, I think.  
> 
> This might be annoying and fragile if the programmer had to get the
> adapter every time IMHO.  Maybe this solution could move towards the
> idea of this kind of wrapper being part of the traversal mechanism,
> which might just be the best thing--I haven't thought that through, and
> I haven't heard anyone actually propose it, and it probably is a bit
> frightening :-).  

Hey, that's a cool idea! I have no idea how it would play out, but it 
deserves some thought :)


> The other approach (which I have on occasion espoused) says that folders
> might need to send some of the pertinent events themselves about their
> contents.  If this were the case, we would simply need to raise errors
> whenever someone tried to do something such as what you describe (i.e.,
> the object hub might say to a registered object that tried to move into
> a non-event-sending folder, "sorry, you can't move *there* because I
> can't hear you!")

Too Zope2-mixin-classy for my tastes ;)


>>So, _if_ all objects are tied into this system, does it make sense to
>>treat "add and register" as an essentially atomic action?  What's the
>>use case for having an object that exists but doesn't generate an event
>>- and does the existance of such objects compromise the effectiveness of
>>the system from a subscriber's pov?
> 
> Hopefully my previous blather answered this a bit too.  We want the
> EventService (most) everywhere, but probably not the ObjectHub.

Right.


>>I presume that event notification happens after a transaction completes,
>>in case something breaks after event notification and the whole thing
>>has to be rolled back.  Further, I presume that each notification is a
>>new transaction?
> 
> While you can make subtransactions, the transactions we are talking
> about here are big: they usually begin at the start of an http request,
> continue on through how many ever things are done and events are fired
> and responded to and so on, until the http reply is sent back to the
> requester and the transaction is over.  More or less anyway. :-)  So if
> anything in the whole process is unhappy, the whole request goes away.

I imagine there will be an EventChannel for processing some events for 
certain clients at the end of a so-far successful transaction. This is 
the system of "triggers" used in ZPatterns / TransactionAgents. However, 
this isn't such an important feature for the mainline event service / 
objecthub.
Jim Fulton has also mentioned an EventChannel that saves up events, and 
sends them out batched up every minute or so. This can have some very 
good effects on the resources used then cataloguing changing content.


>>>Here's the best use case I've been able to come up with for the
>>>distinction. If we want a cascading delete from a relationship
>>>service--that is, a relationship type set up to remove the paired
>>
>>object
>>
>>>if one object in a relationship is deleted--then unregister and remove
>>>might have important implications:  an "object removed" should spark
>>
>>the
>>
>>>cascade delete, but an "object unregistered" should probably raise an
>>
>>Where in the transaction system does this fit?  What happens if the
>>second delete/unregister fails?
> 
> 
> then the whole thing rolls back, unless you *really* want it to commit
> partially, in which case you code it that way.


Yep -- except for the special eventchannels I mentioned earlier, all 
Events in the Zope 3 EventService occur synchronously and within the 
same transaction. This means that when you call 
EventService.publish(SomeEvent), all the clients for that event get 
notified and do all of their processing, and then the call returns.

This is one of the reasons that the EventService filters events based on 
the type of event, and there are EventChannels to further filter and 
route events. You don't want unnecessary things happening when you send 
off an event, as that will slow everything down.

--
Steve Alexander