[DB-SIG] checking column types from cursor object in a database-independent way?

[Michael Bayer]

On Apr 22, 2013, at 12:44 PM, Dan Lenski <dlenski at gmail.com> wrote:

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


well I will say that there is precedent for this specific request - the cursor.connection attribute is part of the spec, and is pretty harmless, and the spec also includes the option for the DBAPI exception classes to be attached onto the Connection, which you can see here: http://www.python.org/dev/peps/pep-0249/#optional-db-api-extensions.  If we're sticking the module-level exception classes directly onto the connection (which I find kind of distasteful, but there it is), might as well put *all* module-level constants onto it.


> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> http://mail.python.org/mailman/listinfo/db-sig