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 <dlen...@gmail.com> wrote: > On Fri, Apr 19, 2013 at 11:46 AM, Michael Bayer > <mike...@zzzcomputing.com> wrote: > > > > On Apr 19, 2013, at 1:56 PM, Dan Lenski <dlen...@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@python.org > http://mail.python.org/mailman/listinfo/db-sig >
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
