[Zope3-dev] Re: ObjectHub should change data structure

[Jim Fulton]

Phillip J. Eby wrote:
> At 05:48 AM 6/27/03 -0400, Jim Fulton wrote:
> 
>> Gary Poster wrote:
>>
>>> Hi all.  We built the ObjectHub services as a hubid->path mapping.  
>>> This was appropriate as a "get it done" solution.  Now it's time to 
>>> optimize, and to consider a more scalable solution, in which a 
>>> renaming or moving of a parent folder with tens of thousands of 
>>> objects does not cause a large amount of data churn.
>>
>>
>> If what you mean by data churn is interacting with each of the contained
>> objects, I'm not sure this is avoidable.  The issue is much bigger
>> than hub information. There are other objects beyond hubs that care
>> when objects change their location.  We also have hooks need to 
>> potentially
>> be called on each object.
> 
> 
> Just a thought, but given how much work generally has to be done to 
> associate an object with its context (i.e., path) in Zope, would it be 
> really such a bad thing to have objects know who their parent(s) are?  

This is a question that I ask myself regularly. :)

Let's look at the pros and cons of using parent references instead of
context wrappers:

   Pros:

     o Much simpler and much more Pythonic

     o Object references can be direct.
       This is a big deal.

   Cons

     o Requiring all objects to manage their parents
       would be intrusive.  Zope 3 wants to avoid any
       requirements on content objects.

       <wave member="hands">
       Perhaps this could be mitigated by permanent
       decorators.  Such decorators might even be
       used to avoid mixing in persistence in some cases.

       That is, when we add an object to a container and the
       object isn't parent aware, we put it in a decorator that
       is and we store the decorator in the container.
       </wave>

     o We'd sort of like to allow an object to be able to
       have more than one parent.  OTOH, while I'd like to
       to be able to do so in theory, it is generally
       inconvenient in practice.

       For example, synchronizing to the file system is an
       important feature. The file system is pretty much hierarchical.
       Synchronizing a non-hierarchical object system to
       a hierarchical file system introduces lots of complexity.

     o Parent references introduce circular references

       While Python does have cyclic GC, I'm unsure of it's affectiveness.
       Collecting cyclic garbage is slower that collecting non-cyclic
       garbage.

       Similarly, ZODB has cyclic GC, but, for some newer storages,
       we can automatically get rid of non-cyclic garbage *without
       packing*.

     o It's a big change. :)  We have a long history with context
       wrappers. Then again, that history hasn't always been a happy
       one.

While I hate to revisit so basic an architectural decision, it is
worth contemplating. I'd be interested in what people think about this.

I'm going to stand back and see what, if anything, develops in this
thread.

Jim

P.S.  A tactic of mine is to put issues out on the list and
       see what y'all come up with.  I'll often not respond to
       comments because:

       - My time is necessarily rationed, and

       - I'd like to see what y'all think without guiding the discussion
         too much.

       Later, when it's time to act on an issue, the discussions are
       a valuable source of input.





-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org