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 hypothesis wrong.

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

Reply via email to