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

Vernon D. Cole vernondcole at gmail.com
Mon Apr 22 11:14:34 CEST 2013


You have a very good point.  Perhaps we should put that on the wish list
for API version 3.

The .connection attribute of the cursor is optional.  IMHO it should be
required..  I think most existing api packages implement it.

The it is suggested, but not required by the PEP, that the exception
classes "should be exposed on the
as attributes (in addition to being available at module scope)."
Adding them to the class definition for Connection is not difficult, and is
quite convenient to use.  I don't like the extra symbols in my debugger,
but I can live with it.  It would be trivial to include the type objects
and constructors there, too.  Again, perhaps this should be required.

On Sun, Apr 21, 2013 at 7:50 PM, Dan Lenski <dlenski at gmail.com> wrote:

> 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.
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> http://mail.python.org/mailman/listinfo/db-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130422/5a67da0e/attachment.html>

More information about the DB-SIG mailing list