Just out of interest,
This SQL-API sounds remarkably similar to ROE in smalltalk. Did you guys
get any inspiration from this particular project ?
regards,
Huy
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
-------------------------------------------------------
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
