A few months past, Ian Bicking (of SQLObject fame) presented an idea for a SQL-API which would overlap significantly with SQLAlchemy. The goal is to represent SQL as Python objects and provide other helpful features (such as information schema introspection) which are not part of DB-API. What is important about SQL-API is what it isn't: abstractions beyond what the SQL syntax supports directly. This to me is quite important.
Back in November or so, I looked at SQLAlchemy when I started to re-write my own SQL-based application. I became quite torn. While I think SQLAlchemy does some very innovative things (mapping, etc.), those things got in the way with what I wanted: a straight-forward representation for meta-data objects, SQL statements, etc. As a result, I have lots of effort which duplicates SQLAlchemy, as I'm sure many other projects also do. The result is unfortunate, I have things that I'm sure SQLAlchemy could use, and vice versa. What I'm proposing is a joint-effort. We work together on a SQL-API specification (as PEP), together with an implementation and test suite, as defined by these goals: http://www.sqlobject.org/sqlapi/goals.html It will be a quite a bit of work, we'd have to have SQL-API use a "factory" pattern for both meta-data objects like Schema, Table, Column, as well as query-components like Select, Where, From, etc. In this way, specialized versions for SQLObject, SQLAlchemy, and similar tools could provide sub-classes of the base SQL-API implementation. While this would require a good deal of effort on you teams part, I think it would pay off. I have several tools that I'm picturing could be build on top of SQL-API and shared, for example, a "schema migration" tool. Another example might be a graphical query builder, etc. Th advantage to SQLAlchemy in the long-run could far out-weigh the short term inconvenience. I'm proposing this in part since we might have additional labor to assist us. Igor A. Murashkin has proposed work on SQL-API as part of Google's Summer of Code. I'm sure in his work he will, of course, "borrow" as much as possible from SQLAlchemy (and other projects). What I'd like to see, further, is a concerted effort on his part to gather specific requirements from SQLAlchemy, and to work with your group refactoring SQLAlchemy to use SQL-API. Please let me know what you all think. Cheers, Clark ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
