<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [DB-SIG] Controlling return types for DB APIs</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Anthony Tuininga wrote:<BR>
> cursor.setdefaulttype(databaseType, type)<BR>
> connection.setdefaulttype(databaseType, type)<BR>
><BR>
> What this method would do is specify that whenever<BR>
> an item that is represented on the database by the<BR>
> given database type is to be retrieved, the specified<BR>
> [Python] type should be used instead of the default.<BR>
> This would allow for a global or local specification<BR>
> that numbers are to be returned as strings or<BR>
> decimal.Decimal objects or that strings are to be<BR>
> returned as unicode objects, for example.<BR>
><BR>
> cursor.settype(position, type)<BR>
><BR>
> This would allow specification of the type to use<BR>
> for a particular column being fetched.<BR>
<BR>
As soon as you provide cursor.settype(dbtype, pytype),<BR>
you should expect someone to ask for<BR>
"pytype = cursor.gettype(dbtype)", and once you've written<BR>
that, you'll realize they're both spelled better as<BR>
"cursor.types[dbtype] = pytype" (for set) and<BR>
"pytype = cursor.types[dbtype]" (for get). Same thing<BR>
goes for adapters: once you allow people to set them,<BR>
you should expect people will want to inspect them.<BR>
So a cursor.adapters object (copied from a similar<BR>
connection.adapters object) should be used. Namespaces<BR>
are one honking great idea. The container classes don't<BR>
*have* to use slicing (you could go all Java-ish and<BR>
use get() and set()), but slicing is the most natural<BR>
choice in this case.<BR>
<BR>
You also should be very explicit about the direction<BR>
of each operation when building type- or language-<BR>
translation layers. That is, include the direction<BR>
in the names of every method and object, because at<BR>
some point, people will want to do the reverse.<BR>
A Python method named "coerce" is not as good as a<BR>
method named "coerce_in" or "coerce_from_database";<BR>
the namespaced spelling, "adapter_in.coerce" is even<BR>
better.<BR>
<BR>
> registeradapter(type, databaseType, fromPythonMethod,<BR>
> toPythonMethod)<BR>
><BR>
> This would specify that whenver an object of the given<BR>
> [Python] type is bound to a cursor, that the<BR>
> fromPythonMethod method would be invoked with the<BR>
> value and would expect a return value that can be<BR>
> directly bound to the databaseType. The toPythonMethod<BR>
> method would be invoked when columns are retrieved and<BR>
> would accept the databaseType value and expect back a<BR>
> value of the given type.<BR>
<BR>
That sounds good if by "databaseType" you mean<BR>
"class VARCHAR"; that is, a Python type which models<BR>
a database type. Because there's no such thing as a<BR>
"database value" you can pass to a toPythonMethod;<BR>
it *must* have already been converted into some Python<BR>
object of a Python type (unless you're writing your<BR>
adapters in C). The best you can do is have a Python<BR>
type (designed/selected for minimum information loss)<BR>
to which the incoming value gets coerced before<BR>
passing it to your toPythonMethod for further<BR>
adaptation or casting.<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>