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

[M.-A. Lemburg]

On 22.04.2013 18:59, Michael Bayer wrote:
> 
> 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.

I don't think we should clutter up the connection objects with
module scope attributes that hardly ever get used.

The exceptions are used a lot, so it makes sense to have them
easily available via the connection object - even though I'm not
sure whether that particular DB-API extension was such a
good idea w/r to API design (it's one of those practicality beats
purity things).

Adding access to the database module via the connection object
would allow to resolve all this. The problem
with doing so is that you typically don't want the module
object to be referenced directly by hundreds of objects in your
application and you can also run into problems when reloading
modules or (depending on how this is implemented) circular
references.

A method doing the lookup via the sys.modules dictionary
could resolve those issues:

database = connection.database()
try:
    cursor = connection.cursor()
    cursor.execute(...)
except database.DataError:
    ...

Thoughts ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 23 2013)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2013-04-17: Released eGenix mx Base 3.2.6 ...     http://egenix.com/go43

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/