On May 10, 2006, at 1:32 PM, Ian Bicking wrote:
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.
theres definitely a lot of ways to construct SQL for sure, such as DejaVU which does them through bytecode. Also Hibernate's HQL, which is string based, is very interesting and maybe something could be adapted from that. In theory, people could write libraries for stuff like this on top of the python-expression systems like those of SQLAlchemy/SQLBuilder....having a set of objects like Select, Join, etc. strike me as the lowest common denominator tools like these would share at an implementation level.
------------------------------------------------------- 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
