Jonathan Ellis wrote:
> I've been trying to keep these things extracted from SQLObject2 in the
> form of SQL-API ( http://svn.sqlobject.org/sqlapi/trunk). I would
> certainly be interested in reuse on that level, and I'm very open to
> suggestions and changes, or whatever. It's intended to be a more
> layer on top of the DB-API.
> I did look at SQLAlchemy before writing sqlapi.sql (which is like
> sqlobject.sqlbuilder or sqlalchemy.sql). There were some small details
> which bothered me in SQLAlchemy, particularly the binding from SQL to a
> specific database engine. sqlapi.sql follows sqlbuilder in this
> respect, where an expression is abstract from any backend until it is
> actually executed.
> I obviously don't speak for Michael, but I don't think that's something
> he considers essential to SqlAlchemy's nature, as long as the different
> backends eventually turn it into appropriate idiomatic SQL. And as long
> as the code doesn't get more complicated for a somewhat theoretical
> benefit... :)
Yes, he said that it wasn't that important in a comment on my blog as
well. It is important for me -- I create SQL expressions at module
import time, when there is no configured database. And I want the
ability to switch databases dynamically even after import. So if a SQL
expression was bound to a connection then I wouldn't be able to keep any
SQL expressions, only calculating them on the fly.
I'd rather the binding not be optional either, as that creates a set of
methods (e.g., execute) that are only valid to some users in some
situations. It seems like a container that embodies both commands/SQL
and connection would be better.
> Some other parts of SQL-API are I think thoroughly outside of the core
> scope of both SQLObject and SQLAlchemy; things like creating, pooling,
> and potentially configuring connections. These things in SQL-API can be
> used in part or in whole.
> SqlAlchemy does provide a connection manager/pooling mechanism that can
> be used independently of the higher-level ORM stuff.
> Lastly, it would be great if there could be some collaboration on a
> combined administration/migration tool, similar in scope to
> sqlobject-admin. ORM-specific administration isn't really very useful
> -- especially when you can't be sure the ORM describes anything similar
> to what some legacy database looks like (before the upgrade). And the
> kinds of functions you want to upgrade a database (ALTERs and table
> introspection, etc) are relatively uncommon in everyday database use, so
> including them in an ORM is unnecessary scope creep. I think a
> cross-ORM tool (and just as applicable to no ORM) would be an easy
> for collaboration.
> If there were a shared substrate at the "sqlbuilder" level, such a
> tool's compatibility would be the next step up. And that would be a
> Good Thing.
I'm not set on any particular implementation detail of SQL-API. If
everything that is in there currently is thrown away and replaced with
stuff extracted from SQLAlchemy, that doesn't bother me at all. I have
stronger opinions on the scope. I don't think it should include
anything frameworkish -- meaning, no inversion of control, nothing that
requires subclassing to be useful, and few logical abstractions. Well,
I'm currently breaking that for the database backend plugins, which form
a kind of framework with an abstract base class, but I'm less concerned
from that perspective -- there should only be a handful of such plugins
anyway, small compared to the number of people consuming the client end.
If anything, I'd like to decrease the scope from what's there now.
As an example of what I think SQL-API can accomplish, I was working with
Django the other day, and it has both its own configuration for
databases (a set of variables, some of which aren't applicable to all
backends), and I couldn't find a way to watch the queries (no logging
that I could find), and the pooling for SQLite was broken (the same
problems that there have been with SQLObject too). Stupid details, none
of which have anything to do with Django's added value over DB-API, and
none of which have any reason to be solved in a Django-specific way.
SQLObject has the same stuff, and now SQLAlchemy, and no doubt other
systems as well.
I tried out bzr last night on a lark, thought about putting SQL-API in
that... but it didn't feel right to me, and doesn't seem important for
this project in particular anyway. But anyway, commit access to the svn
repository is available for anyone interested in working on this.
Ian Bicking / ianb@... / http://blog.ianbicking.org