[Z3-sqlos] zope 2.x, Five and sqlos

[Brian Sutherland]

On Fri, Apr 07, 2006 at 09:48:52AM +1200, Peter Simmons wrote:
> Hi Brian,
> 
> Thinking about your comments "But beware, thare be dragons here, 
> FiveSQLOS contains some _really_
> black magic and I strongly urge you to stick to Zope3 unless you have a
> very good reason not to do so. " a bit more.

The black magic of FiveSQLOS is related to the Acquisition and SQLObject
meta-classes. You cannot make an object that sub-classes from both of
them. But if you want to use SQLObject's in Zope2, you need an object
with properties of both these classes. This is complicated by the fact
that even a Zope2 SimpleItem is so complicated.

For that we use a this voodoo type wrapper:
http://codespeak.net/svn/z3/sqlos/trunk/Zope2/FiveSQLOS/wrapper.py

But there is good news on the horizon, I just saw a mail on zope-dev
talking about having a containment based alternative to Acquisition. If
Acquisition is not required in Zope 2 anymore most of the dragons are
slain.

Also, in my opinion, the way the containers in both sqlos and FiveSQLOS
work could use a big re-think. I know others are using their own custom
containers, but none have been contributed back yet.

> Probably this hasn't been tested in a real world situation but in your 
> opinion would this black magic be a big risk in terms of scalability and 
> performance?

FiveSQLOS is untested (I only know of 3 smallish sites using this) but
          it is a very thin layer

sqlos seems to have gotten most of the kinks out of the lower layers and
      I have heard of it being used in pretty large sites.

The SQLObject and Zope3 combination is being used in a very large
installation (http://launchpad.net).

> One of the things that will happen with this site is it is likely to 
> grow to a few hundred thousand users (and milliions of transactions) in 
> the next 12 - 18 months. We are trying to future proof against that as 
> much as possible. Our main thrust is in getting the data into a SQL db 
> (likely mysql) which handles these numbers of objects/rows much better 
> and fits because largely the data is relational in nature. Our general 
> concept is let's go with some kind of object relational mapping to make 
> the transition easier and more reuse of the exisitng code and then 
> if/when/where required we can always do direct SQL to make things more 
> efficient.

Relational-object mapping also makes it easier and more natural to use a
lot (but not all) of the Zope3 technologies as a lot of them are object
centric.

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
              And she's EVIL!!"