Re: checking column types from cursor object in a database-independent way?

Dan:

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
Connection<http://www.python.org/dev/peps/pep-0249/#connection>objects
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.
--
Vernon




On Sun, Apr 21, 2013 at 7:50 PM, Dan Lenski <[email protected]> wrote:

> On Fri, Apr 19, 2013 at 11:46 AM, Michael Bayer
> <[email protected]> wrote:
> >
> > On Apr 19, 2013, at 1:56 PM, Dan Lenski <[email protected]> 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  -  [email protected]
> http://mail.python.org/mailman/listinfo/db-sig
>

_______________________________________________
DB-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/db-sig