[Zope-dev] Multi tier partitioning meaningful in some Zope apps ?
Patrick Phalen
zope@teleo.net
Thu, 9 Dec 1999 09:46:34 -0800
[Greg Ward, on Thu, 09 Dec 1999]
[snip lots of wonderful stuff deserving of further separate discussion]
:: I was referring to ZODB; two aspects in particular:
::
:: * involuntary use: all my user interface code (DTML methods and
:: documents) goes into this big mysterious object database.
:: I have nothing against object databases, and I'm glad to
:: see a free one for Python. But dammit, to me this stuff isn't
:: data, it's *CODE* -- and code is far too precious to entrust
:: to a database. I want it in a filesystem with full CVS control
:: over it. I want to be able to back it up with tar or afio,
:: one file at a time (or rather, restore it one file at a time,
:: if need be). I don't want my code locked up in this big
:: box of data.
::
:: * voluntary use: object database are good. Python is good. Why
:: can't I put my Python objects into an object database, dammit?
:: Well, I suppose I can, now that there is ZODB. However, it's a bit
:: new and -- AFAIK -- has really only been put through its paces in
:: the context of Zope. More importantly is the limitiation of one
:: data store per Python interpreter. I want to draw a strict line
:: between "my" objects (those "business objects" that represent the
:: stuff important to what we're doing) and Zope's objects (all those
:: DTML things that I really wish were in the filesystem where I can
:: see them). Seems to me that the best way to do that is to give
:: Zope a data store, and to give me a data store. Oops. Can't
:: get there from here... sigh...
OK, I'm completely ignorant about everything I'm just about to say,
and anyone with something remotely useful to do right now should just
move on; but I'll say it anyway, in the hopes of learning something or
provoking someone who knows what they're talking about to come up with
another thought.
I *think* this is akin to what I was thinking about yesterday when I
asked Merlin (Jim Fulton) if he'd ever considered using the ReiserFS
under Linux as an alternative way to get around the one big bag of data
(and maybe even the 2GB file limit) for an object store. I'm thinking
that ReiserFS, now that it has journaling, might offer the chance to
implement a filesystem-based, balanced-tree store of objects, with
some optimized intermediary metadata store. I'm guessing this might
just be too painfully slow; and of course it isn't portable.
If this is too stupid to deserve comment, please comment anyway, so
I'll at least know that it's finally time to go get that job wearing a
paper hat. ;)
would-you-like-fries-with-that-sir?-ly y'rs -patrick