[DB-SIG] Controlling return types for DB APIs

Art Protin 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 
cursors .datetime_type
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 
'object' respectively.
The cursor objects inherit their initial setting of this attribute from 
the attribute
.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 
getting the
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 
DBMS native
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 
a few
subtypes or even no subtypes  Some of the subtypes make a major 
difference in
the conversion function behavior (like those for DATE) and some make 
nearly none.
My conversion routines are called based on the main type but need both 
the data
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,
    Art Protin

>DB-SIG maillist  -  DB-SIG at python.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070417/fcfadaf3/attachment.html 

More information about the DB-SIG mailing list