[DB-SIG] Other extensions

Michael Bayer 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  
> 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.

More information about the DB-SIG mailing list