[DB-SIG] Other extensions
mike_mp at zzzcomputing.com
Tue May 15 21:29:41 CEST 2007
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
> interfaces are then called "Object-Relational Mappers"  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.
More information about the DB-SIG