[Zope3-dev] Zope 3 web root

Shane Hathaway shane at hathawaymix.org
Thu Feb 16 03:19:13 EST 2006

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.


More information about the Zope3-dev mailing list