[Zope3-dev] ObjectHub notes: removing objects

[KevinL]

On Sun, 2002-10-20 at 06:57, Gary Poster wrote:
> While I agree with you, Steve, that the meaning is in fact different
> between the two objects, I cannot think of an excellent use case for
an
> Object Hub client that actually *cares* about this distinction.  If I
am
> a relationship service, if something tries to break the registration
of
> an object for which I have a relationship, I am equally concerned
about
> the event (I must delete the relationship, or I must raise an error
> stopping the registration removal) as if the object were being
removed,
> and my actions are the same.  If I am a metadata cache service, again,
> my actions are identical in both cases (remove the metadata).  If I am
> an indexing service, my actions are identical (remove the pertinent
> hubid from my indexes).

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

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

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?

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?

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

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

KevinL