Michael Bayer <mike_mp <at> zzzcomputing.com> writes: > On Apr 21, 2013, at 9:39 PM, Daniel Lenski <dlenski <at> gmail.com> wrote: > > > > > I *could* pass around a handle to the DB module along with the cursor > > itself, as you've suggested, but that seems redundant and error-prone > > to me. To my mind, this is a small gap in the DBAPI design: > > (1) DBAPI does specify a set of module-dependent type objects > > against which column type objects are to be compared > > (2) DBAPI does specify a cursor object which will produce column > > type objects after a query is executed > > (3) DBAPI *doesn't* provide any way to get from the cursor object to > > the module-defined type objects, at least not without passing around > > module-dependent object. > > IMHO, the DBAPI is not meant to be used as a direct API within higher level application code; it only aims to > provide a consistent low-level API to a wide variety of databases. It should always be framed within some > kind of abstraction layer within real-world application. Therefore it should not concern/complicate > itself worrying about convenience accessors, this only makes it more difficult for DBAPI implementors, > leads to greater inconsistency between implementations, and makes it harder to test for compliance. >
I get your point about not crufting up DBAPI with a bunch of high-level features that will need to be reimplemented for each module... But this seems to me precisely the kind of feature that *should* exist at this level, because it makes it easier for higher-level interfaces to manipulate the underlying database objects in a generic way without carrying around extra module-dependent state on their own. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
