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 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... :)
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 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.
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 / [EMAIL PROTECTED] / http://blog.ianbicking.org ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
