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

[Shane Hathaway]

Phillip J. Eby wrote:
> At 12:28 PM 6/27/03 -0400, Shane Hathaway wrote:
> 
>> The project is a CMS with a repository model, where all content goes 
>> into a big bucket.  The big bucket is an important part of the 
>> architecture, since it facilitates staging and sharing content among 
>> sections.  Yet the customer also needed to be able to confine users to 
>> editing objects located in particular sections.  Zope's security model 
>> made this difficult.  We couldn't grant the limited users permissions 
>> for the entire repository.  Applying local roles to every object in 
>> the repository would be a burden, and wouldn't work if there are a lot 
>> of users.
> 
> This sounds to me like an example of a use case for rule-based security 
> (aka "computed local roles" in Zope 2 terminology).

Maybe.  Like you, I would *really* prefer storing parent references, 
since the current situation imposes large burdens.  Virtually everything 
needs to be context-wrapped, and that's probably a more intrusive 
requirement than storing a parent reference.  It also means that ZODB 
objects have no way to get their parent, increasing the complexity of Ape.

There is a small number of important places where you need the parentage 
to be dynamic, but it would be nice to solve these some way other than 
through wrapping.  By wrapping so much, we might be making the whole 
application suffer to solve the needs of a few rare components.

Brainstorming...

- Copy objects out of the database when you want them to appear in a 
different context.  Assign the copies to a special data manager (_p_jar) 
that copies all changes back to the real database (except changes to the 
parentage).  Then change parentage in the copies.  With some 
optimization and caching of copies, this might work, and might require 
no changes to ZODB.

- Open multiple ZODB connections in a single thread to work with objects 
in multiple contexts.  Like the first idea, the objects from each 
connection must be kept in sync, but ZODB itself would manage the 
copying and caching.

- Restrict objects to having only one context per thread.  We would need 
some kind of _p_parent attribute and a way to prevent threads from 
trying to use an object in multiple contexts simultaneously.  If this 
works, it will probably be a pretty simple solution.

Shane