[Zope3-dev] Re: Zope 3 web root

Shaun Cutts shaun at cuttshome.net
Wed Feb 15 21:30:25 EST 2006


> Max M wrote:
> > The problem is that all the people used to LAMP will come to Zope
and
> > think "Well I will need to think differently here. Thats a bother. I
> > will use sql for everything like usual." And so we will get a lot of
> > duplicated efforts and half-baked Zope developers, who will
desperately
> > try to use Zope for SQL development.
> 
> Because of this concern, I'm putting this off for a while.  I think it
> addresses a major hole in Zope, but it also creates two ways to
> accomplish similar tasks without a clear division between the two
ways.
>   Note that the Python language, despite its philosophy, has at least
> two ways to accomplish things: with functions or with classes.  In
this
> case, two ways are definitely better than one, IMHO.
> 
> But before Zope acquires a new way to create web sites, we need to
> better understand whether that's a burden Zope ought to bear.  It
could
> turn out that people who don't want ZODB really shouldn't use Zope at
> all.  I would find that conclusion disheartening, but maybe it's
> realistic.
> 
> Shane

I think that the discussion about whether one could or should completely
replace ZODB with SQL is less important than providing good connections
to SQL while other things are done with ZODB. (After all -- python
provides functions and classes, but it never says: either develop only
with one or the other!)

In my application it is perfectly clear (for the moment at least:)) what
things are part of the UI/application interface (ZODB) and what things
are data that needs ACID transactions, write-ahead logging and ODBC
(Postgres).

In general, many people who use relational databases do so for a good
reason. I once worked on a project where we had to rip out ObjectStore
after much frustration delay and expense for scalability reasons.

What I'm having to write myself in this project, would have liked to
have had, and perhaps wouldn't mind contributing to ZPL versions, are
containers that allow one to open a window on the SQL world rather
seamlessly.

As it turns out, I've already done my object marshalling because our
system has a Twisted/spread interface as well, so I didn't need SQL
specific object marshalling (though a way of mapping annotations to DB
would have been nice, as I hadn't included that in DB design). Rather, I
just need containers that know that their contents live "out there
somewhere" in a transaction based system that is itself responsible for
object keys.

- Shaun




More information about the Zope3-dev mailing list