<div dir="ltr"><div><div><div><div>Dan: <br><br></div>You have a very good point. Perhaps we should put that on the wish list for API version 3.<br><br></div>The .connection attribute of the cursor is optional. IMHO it should be required.. I think most existing api packages implement it.<br>
<br></div>The it is suggested, but not required by the PEP, that the exception classes "should be
exposed on the <a class="" href="http://www.python.org/dev/peps/pep-0249/#connection">Connection</a> 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.<br>
--<br></div>Vernon<br><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 7:50 PM, Dan Lenski <span dir="ltr"><<a href="mailto:dlenski@gmail.com" target="_blank">dlenski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Apr 19, 2013 at 11:46 AM, Michael Bayer<br>
<<a href="mailto:mike_mp@zzzcomputing.com">mike_mp@zzzcomputing.com</a>> wrote:<br>
><br>
> On Apr 19, 2013, at 1:56 PM, Dan Lenski <<a href="mailto:dlenski@gmail.com">dlenski@gmail.com</a>> wrote:<br>
><br>
</div><div class="im">>> The problem I'm having is... how can I figure out what are the<br>
appropriate<br>
>> type objects for this comparison if I *only* have access to the cursor<br>
object?<br>
><br>
><br>
> Basically I'd question that precondition. I'd look into how the system<br>
is architected such that only a cursor is passed around, and try to<br>
substitute it/augment it with some kind of contextual object; either an<br>
object that can refer back to the DBAPI types, or even the DBAPI module<br>
itself. You can't really assume that ".connection" is present, nor that<br>
the Connection class of the DBAPI is in the same module space as where the<br>
type objects are defined. I'd rework the system and refuse the temptation<br>
to guess.<br>
<br>
</div>I agree that my solution is not a good one... just a quick hack which seems<br>
to work for the modules that I've tried so far.<br>
<br>
However, it seems to me that the precondition is a reasonable one: the<br>
cursor object provides a DB-independent means of obtaining the data from a<br>
query, so why not the metadata as well? Actually, the DBAPI is pretty good<br>
in that regard, because it does establish the different type objects which a<br>
module must provide... but doesn't give a clear way to *find* those type<br>
objects from the cursor object. This makes it difficult to write truly DB-<br>
independent code to manipulate cursor objects.<br>
<br>
I *could* pass around a handle to the DB module along with the cursor<br>
itself, as you've suggested, but that seems redundant and error-prone to me.<br>
To my mind, this is a small gap in the DBAPI design:<br>
(1) DBAPI does specify a set of module-dependent type objects against<br>
which column type objects are to be compared<br>
(2) DBAPI does specify a cursor object which will produce column type<br>
objects after a query is executed<br>
(3) DBAPI *doesn't* provide any way to get from the cursor object to the<br>
module-defined type objects, at least not without passing a around module-<br>
dependent object.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
DB-SIG maillist - <a href="mailto:DB-SIG@python.org">DB-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/db-sig" target="_blank">http://mail.python.org/mailman/listinfo/db-sig</a><br>
</div></div></blockquote></div><br></div>