Jeff Shell wrote:
I agree that better integration with external data should be a
priority for Zope. But what does that mean? In theory, if something's
a Python object it should work with Zope 3 with relative ease... If
that's not the case, perhaps we need to look at how much work is
required to take some random Python object that may be created by some
random data access library and get it into a Zope 3 published web
page. If it kicks and screams and resists security and interfaces, or
what not, maybe we need to take a look at all of that.
Let me focus the discussion: I think it's nearly always a bad idea for
anyone, newbie or expert, to put a template or script in ZODB. Do we
have any agreement on that point? I wish we did. I enjoy ZODB for many
purposes, but not for storing templates and scripts.
The obvious question is, "if templates and scripts are special enough to
not belong in ZODB, what else is so special?" It's really hard to say.
In fact, I can think of rare situations where I actually do want to
put templates and scripts in ZODB.
At one extreme, ZClasses tested the hypothesis that everything,
including code, belongs in ZODB. I think experience has proven that
hypothesis wrong. The persistent code idea in Zope 3 tries to give
ZClasses a new birth, but it seems to have turned out even more
complicated than ZClasses.
At the other extreme, in the Ape project, I hypothesized that nothing
belongs in a pickle database. (I didn't actually believe this, but it
was an assertion I wanted to prove or disprove.) Well, I found out that
the structure of large ZODB BTrees makes them a terrible match for any
kind of object mapping that I cared about, so ZCatalogs clearly belong
in a conventional ZODB storage. I think this was enough to prove the
That eliminates the two extremes, so there's no need to talk about those
anymore. We have to choose what belongs in ZODB and what doesn't, and
the decision is often important but not easy.
I think the distinguishing feature of templates and scripts that makes
them poor candidates for storage in ZODB is the fact that their life
cycle is almost completely independent of the life cycle of a typical
object database. When I'm wearing the software developer hat, my
templates and scripts get packaged and shipped, but my test database
doesn't. When I'm wearing the web developer hat, my templates and
scripts go through a staging process, but my test database doesn't.
Zope doesn't have or want the infrastructure that would be required to
package, ship, and stage complete object databases.
A good practice when developing with ZODB is to zap and re-create the
object database regularly. When I make major schema changes during
development, I delete (or move) the database and fill a new database.
If the database contains anything but test data, I've tied my hands and
can't work efficiently.
Zope3-dev mailing list