On Wed, May 10, 2006 at 01:41:23PM -0700, Ed Suominen wrote:
| So why is it unrealistic to imagine that these lower-level capabilities
| of SQLAlchemy, which are already in place, working, and wonderfully
| documented, could be adopted as the universal solution you're looking
| for? If there's something in particular about those capabilities that
| you don't like, I'm sure constructive suggestions would be welcome.
I don't think it is unrealistic. However, it is definately a different
project, one that focuses on implementing constructs that are directly
supported by the SQL specifications -- and nothing more.
The political issue is that a sub-set of SQLAlchemy is useful quite
broadly, and this just needs its own trunk, with its own release
schedule. It needs its own self-contained documentation as well as
items to support a broader set of applications (it needs to be using
the factory pattern everwhere). The design decisions, although they
should support higher-level systems (like ORMS), should be limited
in scope to directly match the SQL specifications and possibly
quirks from each database implementation.
This work could be carried out in SQLAlchemy's repository /w a branch
which then does items like:
(a) deleting anything that is not directly mentioned in the SQL-92,
SQL-99, and SQL-2003 specifications
(b) move to a "factory" method so that SQLAlchemy and other
systems can provide sub-classed versions of these objects
(c) adding support for things that are in the SQL specifications
that are not already done, such as ARRAY and multi-column
foreign-key constraints, etc.
(d) creating documentation /w explicit cross-references to the
specifications and lots of examples
(e) working on database-specific details as needed
The point of this "sub-project" if you want to view it that way, is that
it will have its own release schedule and scope. It might be that the
current SQLAlchemy trunk requires a version of "sqlapi" that is 2
versions back, etc.
The nice thing about this, is that we have someone who, Google willing,
would be willing to do this, plus quite a bit more (possibly even
helping to update SQLAlchemy to reflect the refactor). There is more
work to be done here: the SQL specifications are monstorous and
providing low-level support for these structures in Python objects
would be a huge boon.
Kind Regards,
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
