On 3/21/06, Ian Bicking <ianb@colorstudy.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.

I'll just refer you to my clp discussion with Steve vis a vis the semantics of "dead end." :)

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.

You're right.  "Keeping things fragmented when there was an opportunity to do otherwise" would be more accurate.

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
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... :)
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 place
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.

BTW, I did end up running with your idea from http://blog.ianbicking.org/towards-php.html ("You have an object that represents your database, attributes that represent tables, etc. There is no "model"; database access is procedural.")  It's in the sqlalchemy trunk as sqlalchemy.ext.sqlsoup.  Documentation pending but it's pretty self-explanatory.  So thanks for that. :)

Jonathan Ellis