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

[Jeremy Hylton]

On Fri, 2003-04-25 at 12:12, Shane Hathaway 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.

It sounds like that's right.  By weak reference, I presume you mean an
indirect reference.  As I said earlier in this thread, I think it would
be helpful to use a term other than weak reference, because weakref has
a specific meaning in Python with respect to garbage collectoin.

> Another possible benefit I've been pondering is the ability for the 
> application to restore context when reacting to ZODB-initiated events. 
> For example, ZODB might tell the application that some object was 
> modified.  The application looks at the object's hubId and uses the 
> object hub to get the path to that object.  Then it traverses that path 
> and invokes some adapter in that context, sending the event to the 
> adapter.  (Batching events might make it fast.)
> 
> So, Jeremy, I'd like to understand this idea of relations better.  What 
> would it look like to the application programmer?

I'd like to understand it better too.  I think the idea is to represent
relations between two objects using a BTree index with properties on the
object themselves to keep a natural Python API.  Here's an example I've
invented to have something concrete to talk about.

class SoftwareProject(Persistent):

    def __init__(self, name):
        self.name = name
        self.developers = rel

class Developer(Persistent):

    def __init__(self):
        self.name = name
        self.projects = rel

rel = relation(Developers, SoftwareProject)

zope3 = SoftwareProject("Zope3")
jim = Developer("Jim Fulton")
stevea = Developer("Steve Alexander")

zope.developers.add(jim)
zope.developers.add(stevea)
assert zope in stevea.projects

One idea is that if the relation is populated in one direction, it is
also manifest in the other direction.  I think this means that the
system is reponsible for providing referential integrity.

I think there's a way to build indexes on relations, but I'm not quite
sure how it would work.

Jeremy