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

[Daniel Lenski]

On Fri, Apr 19, 2013 at 11:46 AM, Michael Bayer
<mike_mp at zzzcomputing.com> wrote:
>
> On Apr 19, 2013, at 1:56 PM, Dan Lenski <dlenski at gmail.com> wrote:
>
>> The problem I'm having is... how can I figure out what are the appropriate
>> type objects for this comparison if I *only* have access to the cursor object?
>
>
> Basically I'd question that precondition.   I'd look into how the system is architected such that only a cursor is passed around, and try to substitute it/augment it with some kind of contextual object; either an object that can refer back to the DBAPI types, or even the DBAPI module itself.    You can't really assume that ".connection" is present, nor that the Connection class of the DBAPI is in the same module space as where the type objects are defined.   I'd rework the system and refuse the temptation to guess.

I agree that my solution is not a good one... just a quick hack which
seems to work for the modules that I've tried so far.

However, it seems to me that the precondition is a reasonable one: the
cursor object provides a DB-independent means of obtaining the data
from a query, so why not the metadata as well?  Actually, the DBAPI is
pretty good in that regard, because it does establish the different
type objects which a module must provide... but doesn't give a clear
way to *find* those type objects from the cursor object.  This makes
it difficult to write truly DB-independent code to manipulate cursor
objects.

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.

Dan