On May 10, 2006, at 4:18 PM, Clark C. Evans wrote:
| 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.
Yes! This is exactly the reason why I've been unable to use SA
directly
in my work. I'm also generating SQL, but under a substantially
different mechanism than you have. While you do many of the things
that
the SoC proposal details, you do it in a way to directly support the
automated SQL generation that you're product requires.
I'd like to see a low-level API for generating SQL that does not
contain
assumptions about *how* the SQL is generated, ones that directly match
the SQL productions found in the specifications, with no magic. This
object system would be "factory" based, so that SA or any other
project
could provide sub-classes with additional features that represented
the needs of you're specific SQL generation process.
no, thats not good enough, the mechanism by which SQLAlchemy
generates the SQL can also be totally separated from the constructs.
the constructs dont know anything about their own compilation. you
might talk about one or two methods at the base of the class
hierarchy that "suggest" the entry points to the included compiler's
interface, but stuff like that is incredibly trivial and is not a
reason to go off and write something totally different.
the subtle features I refer to are things like being able to target
columns from their originating Table all the way up to any Select,
Alias, or union (CompoundSelect) object that was ultimately derived
from that Table. such a thing seems kind of exotic but its very
useful when building ORM's on top of the API, not just SA's API but
any ORM. This is the kind of feature that would entirely not be
apparent when building a SQL construction API for which nothing has
been built on top of. I think features like that need to be
considered when creating a spec that is going to subsume SA's SQL
functionality.
So i am not talking about exposed implementation details... I dont
think theres much of that going on in the public API at all.
also, this word "magic" has got to be put to rest. what is
"magic" ? its the most overused term now which basically has become
to mean, "code that I havent looked at and therefore dont
understand". a more useful definition of "magic" is, an interface
that changes itself in a way that does not correspond directly to its
immediate sourcecode, i.e. monkeypatching. SQLAlchemy's SQL api does
not use any monkeypatching. The class hierarchy is what you get.
-------------------------------------------------------
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
