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.