[Zope3-dev] zwiki: performance of findChildren()

[Shane Hathaway]

Guido van Rossum wrote:
>>In Zope (both Zope 2 and Zope 3), we want to be able to refer to objects 
>>in context.  As you know, the OID doesn't tell you enough to do that. 
>>You usually don't want to use paths to refer to objects in context 
>>either, since the path can change.  You don't want to make a registry of 
>>OID to path, since OIDs should not have any meaning to the application.
>>
>>So the ObjectHub solution is to assign a new arbitrary ID to objects--a 
>>"hubId"--and keep a registry of hubId to path.  That way an object can:
>>
>>- Make "weak" references to other objects
>>
>>- Refer to an object even if it moves or gets exported/imported
>>
>>- Avoid depending on OIDs
>>
>>So, that's my understanding of the core of object hub.  Correct me if 
>>I'm wrong, anyone.
> 
> 
> Sounds right according to my own feeble understanding.
> 
> Which leads to a suggestion (mayby Gary can refute it): why not use
> OIDs as hubids?  Is this because OIDs are fairly long (e.g. 8-byte
> strings)?  Or is it because you don't know a new object's OID until
> after the transaction that creates it is committed?

Well, if you're using mounted databases, you'll probably get overlapping 
OIDs.  A way to deal with that would be to use (database name, OID) as 
the hubid.  Then database names would become unchangeable, which 
probably isn't a big burden, but not ideal.

Also, for better or for worse, Ape puts paths in OIDs when mapping to 
the filesystem.  I could not find any other way to map to the filesystem 
in a scaleable way.  If Zope 3 uses OIDs as hubids, it will be 
impossible to move or rename objects stored using Ape's filesystem 
mapper and still retain hub references.

In general, I believe it is a useful design pattern to let the object 
persistence mechanism have complete control over OIDs, while the 
application maintains its own IDs independently.

Shane