[DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1

[Ian Bicking]

(Since I was writing this up I thought I might as well copy it to DB-SIG
as well) 

On Tue, 2002-10-22 at 00:51, Steve Freitas wrote:
> Could you illuminate for us the differences in
> philosophy and applicability between SQLObject and MiddleKit?

SQLObject and MiddleKit are basically trying to do the same thing --
both cache similarly, for instance, and neither deals with
transactions.  I think MK has some sense of committing changes -- I
can't remember -- but SQLObject currently commits all changes
immediately.  But for the most part when using the objects (as opposed
to defining them), MK and SQLObject should feel fairly similar -- the
differences are more syntactic than semantic.

I can't claim I ever really committed to using MK -- I played with it
some, but that's all.  But I did make SQLObject somewhat in response.

I didn't like the way objects were defined in MK -- CSV files bug me,
and in general I like Python and want to stick to Python.  So you define
the objects (table and column names, etc) just with some special class
attributes.  It uses some Python magic (metaclasses) to turn those into
a fully-functional class definition.  In contrast, MK uses code
generation to pretty much the same effect.  And my vague impression is
that PyDO avoids all this trouble by using the dictionary interface, so
it doesn't have to create methods for each column -- I specifically
didn't want to do something like that, because I don't want the database
columns to be distinguishable from other methods and attributes.  Making
that distinction, IMHO, is a significant compromise of the whole point
of a middle object.

Both SQLObject and MK should perform relatively similarly.  SQLObject
may be faster in some aspects (less function calls, for instance), but I
would not be surprised if this difference was negligible.

SQLObject does not do any data integrity checks, unlike MK.  But you can
use subclassing to do your own checks, just like in MK.  In effect, you
won't automatically catch a column being set to a non-integers despite
its definition.  In practice, SQL handles 10 just like '10', and gives
the necessary errors if you pass a string that can't be coerced into an
integer, so I wasn't very concerned.  True error checking in both cases
requires custom code (assuming your constraints aren't trivial).  I
suppose in more powerful databases you can use constraints in the
database -- but again, that's up to you (as it should be).

MK does schema generation.  SQLObject deliberately does not; schema
generation just didn't seem like a problem in need of solving to me.  I
also want to make as few requirements on the schema as possible.

Both MK and SQLObject currently only work with MySQL.  I hope to extend
SQLObject, and I think it should be very easy (actually, I hope others
will extend it, but I'll help them :).  There's really only one part of
SQLObject that need to be ported -- inserting a row, to be specific.

SQLObject has an experimental feature for selecting multiple objects
(i.e., generating a SELECT statement).  I think it's clever and cute --
I'm not actually sure how useful it is.

SQLObject also happens to use properties, as introduced in Python 2.2. 
Mostly because this is my first 2.2-specific code, and I thought I'd go
all out.  So you do things like "p.firstName" and "p.firstName = 'Joe'"
instead of "p.firstName()" and "p.setFirstName('Joe')" like you would in
MK.

I think that's a fairly thorough explanation.  MiddleKit is more mature,
of course, and has thorough unit tests and all that good stuff.  When
you are actually using them, I think you'll find SQLObject is less
formal and easier to experiment with.  I wanted it to feel thinner,
which I think it does.  (It's also small enough that I don't feel
entirely crazy when I fantasize about it becoming simply Correct, tests
or no tests -- but it's not there yet, of course :)

  Ian