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

[Phillip J. Eby]

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?  All 
of this hubid->path business could just go away, then, at least for objects 
that implemented the 'know my parents' interface.  Also, presumably some of 
the other events could be generated via such a "parent management" 
interface.  For example, moving an object could easily be detected if you 
tell the object to move, instead of deleting from one container and adding 
to another.

If I recall correctly from the complex place-management code I had to write 
for ZPatterns, the majority of the complexity came from the fact that 
containers wanted to manage this stuff, and the contained objects were just 
observers of the process.  It would have been enormously simpler if objects 
were responsible for their location, and responded to e.g. a move request 
by deleting themselves from one container and adding themselves to the other.