Folks,
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
type.
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
database
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.
federico
However, another issue is discovering the available conversion functions
and determining their arguments.
Thank you all,
Art Protin
------------------------------------------------------------------------
_______________________________________________
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
