Clark C. Evans wrote:
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.
My own goals are really something that isn't a framework, but something
more in line to extend and subsume db-api. Specifically leaving out any
ideas of modeling or mapping, with a scope that is mostly procedural.
Right now db-api is rather incomplete, but we all know that. A lot of
what can be added to that isn't a substantial change in API, but just in
functionality; and in doing so, create something as applicable to people
who are most comfortable constructing string queries as to people using
higher-level tools.
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.
I've actually been wondering if a further division would be better.
Instead of defining objects with particular functionality, focus on
simpler protocols (aka magic methods), separately providing
implementations of that. The model that SQLAlchemy and
SQLBuilder/SQLObject use is only one of several models; for instance, I
think it's feasible to use generator comprehensions for selects, and
strings -- perhaps with some annotation -- are a natural starting place
for people who have been using the db-api directly or are coming from
other languages.
Similarly, a more procedural database introspection system is easier to
specify, write, and test, and then higher-level constructs can be built
on top to the specification. So I think instead of emphasizing the
structure of SQL, it might be best to really start at the bottom and
emphasize explicitness over convenience.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
-------------------------------------------------------
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
