[Zope-dev] multiple ZODB files?

[Phillip J. Eby]

At 07:23 PM 1/6/00 +0000, Jim Fulton wrote:
>
>If anyone wants to work on this, I'd be willing to set up a mailing
>list and provide advice. 

Please do.  :)


>Some issues:
>
>  - How to handle references accross databases.
>    At a basic level, this is not too hard, but...
>
>  - How to handle garbage collection in a multi-db environment.
>    Oops.  Storages are currently responsible for GC.  This won't
>    account for references from other databases.
>
>  - How do databases get connected, from a UI point of view.
>    Do you get to specify a database when you add an object?
>    Any object?  Where do databases get defined?
>
>    One idea I just thought of would be to have a databases
>    area of the control panel where one could add database
>    objects that modeled root database objects. Then, perhaps
>    one would do the moral equivalent of a link from an object in
>    one db to another.....
>
>  - .... There are probably other issues I haven't thought of.

The work Ty and I are doing (and which we'll be talking about at the
conference) is asking all the same questions.  However, we're not really
interested in making it all automagic by the system, we're more concerned
with establishing a pattern framework for making storage issues like these
transparent to code at the problem-domain level.

Specifically, we want to be able to write ZClasses whose instances neither
know nor care what databases (relational, LDAP, or ZODB) they or the
objects they relate to are stored in.  We do this by delegation in a
standardized framework, where certain objects have responsibility for
creating, finding, or storing instances that meet an abstract interface.
These "Implementor" objects are environmentally acquired, and thus what
database a thing should be stored in (not to mention what class actually is
instantiated) is seperated from an object's specification of what kind of
thing it wants to relate to.

We haven't yet given much thought into how this could be made fundamental
to the existing Zope framework; we've been more treating it as a layer of
practices for applications built on Zope.  But it might be interesting to
re-examine such scenarios as "folder adds an object" under our model as an
instance of the scenario, "instance asks an Implementor (of abstract type
ManageableZopeObject, let's say) to create an owned instance of an object
and return a storable reference."

(Note, by the way, that we are not yet treating abstract types as being
quite so concrete as the fascinating Interface system you've implemented.
We are viewing them more as loosely defined plug-in points within a
framework, where Implementors provide a spot for someone integrating
different products to add the necessary glue.)