[ZODB-Dev] Newbe ZODB questions

Ken Manheimer klm@digicool.com
Fri, 1 Jun 2001 18:12:51 -0400 (EDT)


On Fri, 1 Jun 2001, Christian Robottom Reis wrote:

> On Wed, 30 May 2001, Patrick Down wrote:
> 
> > 1. I see multiple storages talked about in the documentation but it is
> > unclear if they are implemented.  My application has two separate object
> 
> Multiple storages meaning multiple storage `drivers' -- you can store
> objects in a file database, a bsddb database, and an Oracle database for
> now. All these are provided in the StandaloneZODB package.

I'm missing other context here, but what's cited could be referring to
multiple mounted storages.  Zope.org, for instance, has a separate storage
for the fishbowl wikis (projects and proposals), in addition to the main
ZEO-connected filesystem storage.  The wiki storage is to preserve
historical revisions for all those wiki pages - the wiki storage is never
packed, while the main storage is.

I don't think there's any constraint on the number of storages you can
mount at once.  Another potential use we've considered is for a mailling
list and/or news archive storage - based on a non-versioning storage
("packless") storage, it could grow indefinitely without impact on access
to objects in the other storages.

> > hierarchy are deep copied to the document hierarchy and then modified.  Does
> > ZODB support having more than one storage open?  How would I associate
> > persistent objects with one or the other?

Zope uses a notion of a mount point, like in the unix filesystem.  
Objects targeted within the hierarchy below the mount point goes to the
ancillary storage.  I don't know how it applies ZODB to achieve this - but
you can be it's doable.-)

> > well in a situation like this?  I also have seen discussion that the
> > FileStorage grows with every write and needs to be periodically
> > compressed.  Is this true?

Maybe you'll want to use a different storage mechanism - there's a
berkley-db based (i believe) "packless" storage which doesn't maintain
historical versions, and may be more suited to your purpose.

Ken Manheimer
klm@digicool.com