On 3/21/06, Ian Bicking <email@example.com> wrote:
I haven't said SQLObject is a dead end. I think the codebase needs
rethinking, as well as thinking about what its scope should really be.
And "fragmenting things again"? I don't know what you are talking about
there. Continuing the SQLObject line is not fragmenting things at all.
SQLObject is, after all, the older project.
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 useful
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
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.
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 place