Hi Clark -
Im not really sure what "duplicating effort" you have made, perhaps
you could show me some examples....i havent heard anything about the
current userbase having to "duplicate" parts of SA at all; just
people building new things on top of it (like ActiveMapper, SQLSoup
and Pocoo).
If youre referring to Ian's original critique of SA, that table
objects are necessarily "engine-bound", this is not really true. in
0.1, this was only slightly true, in 0.2, it is not true at all.
The schema and SQL construction modules have always been entirely
disconnected from the ORM as well, so I cant see how the ORM "gets in
the way" of things.
As Ian's early critique of SA struck me as somewhat shallow, I am
encouraged to hear that SQL-API would like to take an eager and in-
depth interest in the techniques used by current toolsets when making
decisions about how it should look and behave, just as SQLAlchemy has
taken an eager interest in SQLObject, Hibernate, and JSR-220. I
think this is required; as the last time I looked at SQL-API I
couldnt see anything to suggest that SQLAlchemy was not a 100%
superset of its capabilities, perhaps with just a little more of an
"in the trenches" style of API. This is of course a product of the
fact that SQLAlchemy is already *in* the trenches and is adjusted
every day in response to real-world issues experienced by users. A
PEP would have to take into account pretty much every issue that SA
has solved for it to be effective, no small task. Under no
circumstances can SQLAlchemy's future afford to get mired down in an
esoteric and ruminative PEP construction process; its no pie in the
sky, and its main goal is to provide Python with a very powerful,
stable and useable "results-based" SQL toolset, giving it a great
advantage over other development platforms that threaten its relevance.
This is complicated by the fact that SQLAlchemy's SQL construction
facilities are highly tuned at this point and have a lot of subtle
features that are not only difficult to implement, but are also very
critical, for reasons that may not be immediately obvious. A major
interface change will almost certainly be extremely time-consuming,
im not sure it would quite be a "short-term inconvenience".
But if the PEP-making process is interested in what SQLAlchemy does
and how it does it, then show me what list to sign up on; while I
have a lot of trouble following the typical "PEP-oriented"
discussion, I can certainly offer my thoughts.
On May 10, 2006, at 2:03 AM, 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.
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
