[DB-SIG] Controlling return types for DB APIs
aprotin at research.att.com
Tue Apr 17 16:51:38 CEST 2007
This conversation is excellent.
I have also experienced the need to extend our driver in non-standard
ways in support
of datatypes (as well as in other dimensions.) I added an attribute to
to indicate whether to leave them as strings (as converted by our DBMS
on output) or to
convert them to datetime objects, indicated by the values 'string' and
The cursor objects inherit their initial setting of this attribute from
.default_datetime_type on the driver module.
I also added another attribute on the cursor which, after any query, has
a list of strings,
one per column, with the type names as they were reported by the DBMS.
Federico Di Gregorio wrote:
>Il giorno mar, 17/04/2007 alle 10.16 +0200, M.-A. Lemburg ha scritto:
>>While this can be solved using a registry of types conversions,
>>I see problems in standardizing the way to define the type
>>mappings since different database backends tend to have
>>or need different types.
>I can see an API that leverages on the introspection abilities of the
>drivers, to abstract to the different type representations of the
>various backends. Let's suppose that a driver "knows" the type of a DB
>column, then we can ask it for an abstract "dbtype":
>dbtype = connection_object.getdbtype("SELECT 1 AS foo")
>where the query _must_ return a scalar from which the driver infers the
I do not see reasons for (1) why this is a connection level method, and
(2) why the
query would need to be limited to returning a scalar. This seems to be
same information that my second extension provides. What am I missing here?
> Then the type can be used as a key in the registry.
Yes, something nice and simple, like a dict using the string name of the
datatype as the index. However, this might not work out after all. Our
system has an nearly unbounded set of types. The types have two
components, say a
major and minor, or a main type and subtype. The main type "STRING" alone
has 65535 subtypes (one for each allowable size). Other main types may
subtypes or even no subtypes Some of the subtypes make a major
the conversion function behavior (like those for DATE) and some make
My conversion routines are called based on the main type but need both
value and the subtype as arguments. Do any of the other systems have
such a multi-level type scheme as this?
> Obviously the
>conversion function will be backend-specific but I suppose the signature
>couldbe the same for all functions. Given the fact that the conversion
>happens inside a cursor and than the connection is available from the
>cursor object itself, something like:
>py_data = conversion_function(backend_data, cursor_object)
>Then we can at least make a standard for the registry methods.
However, another issue is discovering the available conversion functions
and determining their arguments.
Thank you all,
>DB-SIG maillist - DB-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG