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.