ObjectHub

ObjectHub goal:

Provide a unique id (UID) for objects in traversal context. This id is called a hubId.

HubId? closest Zope 2 analog:

A ZCatalog? RUID. Primary differences are that it is consistent (i.e., does not have any semantics of changing on reindexing) and it is exposed (i.e., it is globally available rather than a private implementation detail).

General description:

The ObjectHub keeps track of objects in their traversal context by mapping hubIds to paths. Since traversal context is an important part of the mapping, if the same object were mounted in two locations and both locations were registered by the ObjectHub, then the ObjectHub would consider them to be have two separate hubIds.

The ObjectHub's hubIds are kept valid through object moves, and are removed for deletions. The Zope 3 event system receives the various object change events and delivers them to the ObjectHub for this purpose.

If the object is registered with the ObjectHub, the hub makes any necessary alterations to its own data on the basis of the change and also publishes a parallel hub event to the event service. The hub event is similar to the original object event but uses the hubId as object identifier instead of the path.

ObjectHub subscribers (clients) can then make any necessary changes to their data structure on the basis of the change. They can also choose to raise an exception if the change violates an assertion in their data structures (such as breaking a required relationship) and thus turn back the whole transaction.

ObjectHub clients are typically index-like objects, keeping track of object content, metadata, or relationships. The ObjectHub itself is fairly simple, but it relies on the more complicated event service, and it is part of the larger set of cataloging machinery. Cataloging is not yet done as of this writing (March 21, 2003).

Future explorations:

hubIds are intended to behave as unique ids. Because hubids are only unique to one ObjectHub, having another ObjectHub in your site is a significant and possibly dangerous configuration decision. These patterns have only begun to be explored and are recorded in the Zope 3 wiki under the proposals section as AdvancedObjectHub.

Conclusion:

If you simply want to refer to an object and have something else be responsible for keeping track of the object through any moves, the ObjectHub should be your tool for many such use cases.

Some use cases will want more of a ZODB OID available in application space, in which the id is the same if it is the same object mounted in different locations. These use cases have not yet been thoroughly explored in Zope 3 to my knowledge.