[DB-SIG] Asymmetry in DB-API 2.0 types

Harald Meland Harald.Meland at usit.uio.no
Wed Jun 4 13:05:46 EDT 2003


[M.-A. Lemburg]

> The driver output values are driver dependent and there's nothing
> much the API spec could do about this because not all databases
> support all different kinds of data types and it is not even
> clear for which result columns a specific data type is needed
> or desired.

Wouldn't it be possible to extend the current specification for
e.g. DATETIME:

   DATETIME
     This type object is used to describe date/time columns in a
     database.

to include an API for deciphering such type objects, e.g. like this
(we'll obviously need to work on the exact behaviour of the various
methods, this is just an example to get the discussion started):

     Objects of type DATETIME must support the following methods:

     date()
       Return a string on the form "YYYY-MM-DD" representing the date
       part of the object's value.

     time()
       Return a string on the form "HH:MM:SS" representing the time
       part of the object's value.

     ticks()
       Return the object's value as seconds since epoch; raises
       ValueError if object's value is not representable as ticks.

     year
       instance variable containing the (4-digit) year, as an integer,
       of the object's value.

     ...

The NUMBER type could be required to expose information on
e.g. precision in a standard way, etc.

After all, every driver has to use a *single* type for each value a
query returns; if the value doesn't fit into one of the standard types
mentioned in the DB-API, then the driver is of course free to use some
other type for that.
-- 
Harald



More information about the DB-SIG mailing list