[Zope] - Multiple database files

[Jim Fulton]

Rob Page wrote:
> 
> > I was thinking of some of my development problems with Zope -- for
> > example, it's difficult to work on code at home, tar it up, bring it
> > to work and change it some more, take it home again ... -- and
> > realized that being able to split up the object database into multiple
> > files could help.  Imagine if you could have several Data.bbb files,
> > each holding some subset of the database's objects.  This might be
> > done by specifying into which file an object goes; the object's
> > children go into the same file, unless they're explicitly moved into
> > another file.
> 
> Independent of implementation concerns (boy, that was easy!) I agree.
> I'd also like to see that woven into sessions.  Specifically, I'd like
> to check out a sub-tree to a file, take it on the road and tweak it.
> Since I've got the folder in a session I would essentially have it
> locked for writing.
> 
> When I got back I would replay the transactions into the main site.

I think that you are on the right track to think of this in terms
of sessions.  (I intend to rename "Sessions" to something else
to avoid the more common notion of sessions wrt to web applications
... but until I do...)  Sessions have the advantage that they
don't force you to divide your web hierarchy, they have some locking 
semantics and they are especially well suited to works in progress.

If you are the only person working on a site, you could generally
just move bin/Data.bbb.trans and bin/Data.bbb.trans.index around.

There is a potential problem if the transaction file and data
file are modified independently. As the software works now, 
you should be able to overwrite the transaction file and restart
the Zope process to see the changes.  If someone modified an object
that you also modified off line, then their modifications would
be lost.  Also, it's possible that the integrity of the transaction
in which they modified the object might be compromized.
Still, it might be worth some experimentation.

In the long run, there could be more direct support of this 
sort of thing.  For example, maybe it should be possible to 
have multiple transaction files and a mechanism for negotiating
lock contention between the multiple files and the database
file.  This is something I'll keep in mind for the next
revision of the database.

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.