I just commit a bunch of changes that moved all the SQL out of
SQLObject.py, now all in SQLBuilder and DBConnection.
To test the flexibility of this, I created a DBM backend, i.e.,
non-SQL. It has much of the functionality of the other databases, but
probably has some bad performance issues, since there's no indexing
except on ID (though that can be fixed).
The neat part is you can even use .select(), so long as you use
SQLBuilder instead of creating the SQL yourself. Without indexes (or a
query optimizer) it essentially evaluates the expression for every
possible combination of rows, but for a significant number of queries
this isn't any worse than a RDBMS would do.
Besides amusing me, and proving the potential of SQLBuilder/SQLObject as
a storage abstraction layer (since this is a significantly different
sort of storage), this also can be useful to make SQLObject-based
applications easy to install, with no dependencies (in return for
decreased performance). Of course, SQLite and the not-yet-supported
Gadfly (no doubt easy to support) have similar intentions. But I do
this in ~375 lines of code, which I think is smaller than either of
those :) -- I suspect the lack of SQL parsing is the biggest reason for
simplicity. And the lack of indexing :) But someday...
Having done all this, I'm going to start working on getting a release
together. There's some Postgres and SQLite things that need to be
fixed, and then it should be ready.
Ian
|
