On Aug 24, 2005, at 8:08 AM, Lennart Regebro wrote:
I'm not convinced that Florent blog entry says what Gary thinks it
Hopefully you can see where I would get my interpretation, though.
I'm happy to have Florent clarify on his return. This is a good
discussion in any case.
but I agree with Gary on the other stuff: It should be possible
by configuration, to switch out at least some parts to a relational
The catalog indexes and metadata is a prime example of this. No, there
is nothing wrong with ZCatalog,
Well, I didn't say that, actually. I said that Btrees are excellent
tools; neither they, nor the Zope 3 catalog are hacks; and the pure
ZODB catalog story has compelling advantages over an RDBMS catalog,
in addition to disadvantages.
but it is data like that that
relational databases are sepcialized to handle. For HUGE catalogs,
installing a dedictaed relational database makes sense.
I can imagine situations in which this might be true, yes. That
said, BTrees are excellent for huge data sets. Fixing the ZODB cache
story would be a big step to making them even better.
As Florent pointed out, you may want to do typical aggregational stuff
on meta data I personally thing the right way to o that is by indexing
them in a catalog that supports that, like for example a relation
I suppose. This doesn't strike me as hugely compelling--until
someone explains to me why it wouldn't be, it seems like it would be
easy to implement these sorts of features efficiently in a ZODB-based
catalog if someone cared enough.
Again, my argument is not against O/R mappings, it is on relying on
them exclusively for a shared platform. I'm *very* happy to have us
leverage the component architecture to have different component
implementations for different use cases. That, of course, makes
plenty of sense, and is at the heart of Zope 3.
It would be nice to have some sort of transparent support to choose
how blobs are stored; in the ZODB on disk or in a relational database.
It would be nice to have an easy way for usage statistics to be stored
in a relational database. Storing the in the ZODB is generally not a
good idea (as they tend to make every click a write transaction).
Absolutely. RDBMS should be one option for that sort of use case, as
should rotated flat files, probably. We've used both, for different
Therefore, I agree with what I think Florent tried to say: An
enterprise CMS needs to have relational integration built in, straight
in the core, so that you can, configuratively store certain data in a
I also agree with what I think Gary is trying to say: We should NOT
try to store as much stuff as possible in a relational database.
Cool. I'll expand your summary of my email to say that a relational
database should not be required for a shared "enterprise CMS"
project, but RDBMS-based components, and transparent O/R backends
like Ape, should be configurable options. From other parts of your
mail, it seems you might agree with that too. I hope so.
I would be happy to agree with your interpretation of Florent's blog,
given the caveats from my message, as you and I summarize them here.
Some of Florent's blog is worded in such a way as to make me wonder
if your interpretation is accurate, though. :-)
Zope3-dev mailing list