[Zope] To Zope or Not To Zope?

[Andreas Kostyrka]

On Wed, 26 May 1999, Alexander Staubo wrote:

> It isn't just an issue of compatibility, but also of speed, stability,
> and scalability. Being able to have the Zope piggyback an MSSQL, DB2, or
> Oracle server is definitely a huge comfort, because a _lot_ of man
> hours -- arguably more than in the case of Zope -- have been put into
> those RDBMS tweaking them and securing them. Instead of spending lots of
Yes. But Zope does need an object oriented hierarchical database. Storing
objects in one or more SQL tables buys you the worst of both worlds:
-) You still do have ``binary garbage'' in effect.
-) A extremly good relational table management, when in fact you need
   hierarchical data management, may be beaten in performance, etc. by a
   average to good hierarchical implementation.
-) You pay the SQL server, etc.
-) I'm not that much convinced that SQL used in this manner "SELECT data
   FROM TABLE WHERE pos=123456;" is much faster than "f.seek(123456);
   f.read(512)" 

I can understand your concerns, as they mirror my own very strongly. (Just
lookup my rants in the mailing list archive :) )

I've returned to Zope because:
-) My current projects don't depend upon thread level concurrence. And Z2
   is coming, where exactly this problem is being addressed.
-) The ZPL has become compatible with our mindset :), so perhaps it's
   better to work with the community, instead of playing Rambo ;)
-) I've found some mental balance on this object base stuff.
   Really important data goes into a SQL server. The webinterface goes to
   Zopebase. 

> time finding new, esoteric ways of optimizing Zope's DB, you can
> effectively delegate that work to people who have spend their whole
> lives with their heads inside database algorithms. (Although I admit
> that B-trees are nice.)
But the problem as pointed out is, that SQL server do not solve exactly
the problem Zope Base solves. They solve a similiar problem, but that's
possibly not enough.

> > > scale and compatibility issues, but most of the benefits of
> > using Zope
> > > would be mitigated if I ended up having to write SQL queries
> >
> > Correct.
Not really. Using pluggable Brains (==Python classes for the return set),
you can have many of the benefits, and still have your data stored in the
SQL server.

> I don't agree (if the above sentence means that having write SQL queries
> will diminish the benefits of using Zope). SQL Methods greatly reduce
> the gap between the RDMS and Zope. It doesn't magically objectify the
> "relational" bits, but at least integrates them pretty well into the
> Zope object space.
Ooops, exactly.

> Creations publish products that are commercial and cost $, but I'd
> object to any Microsoft-ish pricing (eg., if you'd sold Confera for
> $1000 I'd definitely balk). So please be lenient, huh? But more than
> that I'd like to ask you what happens when you demote a commercial
> product to a free one. Isn't this unfair to all those people who might
> have bought it?
If there is a need for something, than somebody will implement it. If it
is needed only for a minority of customers, it might succeed some time
without being ZPLed, but if there is a wide need for something, somebody
will recode it to be free. Many things whose license is to restrictive
inspire better free replacements. (Don't ask me why, but license
insecurity creates an itch for many people.)

> The risk from my own point of view is really that Zope's design suddenly
> one day might prove inefficient. For example, what if Zope doesn't scale
> beyond 1000 objects? That's my fear, because such a break in scalability
> may be deep in its design. I doubt that Zope doesn't handle 1000
> objects, because obviously you've done some testing beyond that limit
> (you have, haven't you? Right? RIGHT? :), but since I've not looked
> through all the sources I can never be sure that at some point I'll say
> "I'd like to do..." and somebody will tell me "You can't, because
> internally Zopes this and that as...". That's how Windows tends to work.
Then you fix it. I know design bugs are the most difficult to fix, being
followed by ``nice-design-bad-performance'' bugs on the list; but the ZPL
puts even that in your hand.

In my personal experience, Zope is being limited by:
-) ZODB2 single threadness. Ok, it's less than fun to have to write a
   multithreaded object base, but ZODB3 will be this, so the problem will
   be solved shortly.
-) Python. Well Python is really perfect, with perhaps the exception of
   performance. But again, this is a recognized problem, Python 1.3 was a
   desaster, 1.4 was bad, 1.5 is quite acceptable.
   And for the really problematic stuff, there is always our friend gcc
   on standby.

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.