[Zope3-dev] ObjectHub notes: removing objects

[Gary Poster]

Hey Kevin!  ;-)

On Sat, 2002-10-19 at 19:10, KevinL wrote:

> Can I ask, from a novice's view, how does the Hub system tie in with
> transactions?

sure...simply that the hub system will always be operating within a
transaction, usually that of a web request, so if an error is raised
anywhere, the transaction is rolled back and what you the request was
doing never happened. :-)  This means that we can protect ourselves from
unpleasant situations in the object hub or anywhere else anywhere within
the request handling.

I kinda figure you know most of that, so either (a) I misunderstood your
question, and didn't answer it, or (b) I added some small tidbit which
makes it all fall into place.  Here's hoping for option b. ;-)

> 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).  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 :-).  

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!")

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

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

> Am I way off base?  If this stuff is written up somewhere, feel free to
> answer with RTFM :)

There is no Zope 3 manual--just lots of nice interfaces--but the
transaction stuff I'm telling you is the same as the Zope2 transaction
model, as described in the developer's guide.  As far as I know, that
particular part of things hasn't changed too terribly much.

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

I wish we had a nice intro to get folks started on everything Zope
3-ish--Jim's programmer's tutorial teaches the component architecture
very well but once you get beyond that the interfaces are your best
friends, I think...  If you haven't seen the tutorial check it out
(literally--in CVS--ar ar ar)

Gary