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

Dan Lenski dlenski at gmail.com
Mon Apr 22 03:50:17 CEST 2013


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 a around module-
dependent object.



More information about the DB-SIG mailing list