On May 15, 2007, at 3:00 PM, Robert Brewer wrote: > > It's not so much that making a standard interface is hard (SQLAlchemy, > for example, and my Dejavu/Geniusql do this quite well). It's that > such > interfaces are then called "Object-Relational Mappers" [1] and are > pretty universally shunned as an arena for standardization.
I would hate for the SQL construction facilities of SQLAlchemy, Dejavu, SQLObject, or anything else like that to become "standardized" (if thats what you meant). to me thats the same as picking the one true web framework. both are too high-level to be distilled into a single methodology. There are some various ORM "standards" out there and they are all equally useless/ludicrous. standardization locks out all alternative approaches immediately, it also locks down the selected approach from further development without approval from a committee. the additional levels of bureaucracy inherent in any "standardization" stretches the productivity of the typical OSS working model (read: non-paid volunteers doing this in their free time, as opposed to prominent industry-supported standards bodies like W3, ANSI, etc.) super-thin and should only be used as absolutely necessary (which I believe does include very rudimental "agreements" such as WSGI and DBAPI). DBAPI needs to remain as the most minimal layer of standardization possible (and i think it should remain about SQL. to support other query languages would invariably require much richer APIs)...it just would be nice to iron out the API variances in implementations a little better...particularly things like dates, floats/Decimal, more accurate method specifications (like explictly requiring the named argument "size" when the spec says "fetchmany(size=x)"), expected return results of execute()/executemany(), unicode. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
