[DB-SIG] New update for DB API 1.1

M.-A. Lemburg mal@lemburg.com
Thu, 25 Mar 1999 13:32:44 +0100

Andy Dustman wrote:
> Okay, one more thing that bugs me, and this is somewhat more serious.
> We still have the various type indicators which are inherited from the
> defunct dbi module, i.e. BINARY (was RAW), STRING, NUMBER, DATE, TIME,
> TIMESTAMP, and ROWID. (The constructors seem fine.) DATE, TIME, and
> TIMESTAMP directly correspond to MySQL types. MySQL doesn't have anything
> that corresponds to ROWID.

Then ROWID should not be equal to any description field type code,
e.g. see the example from mxODBC below.

> And there are several types which would qualify
> [...]
> This is what I would propose:
> 1) Make type code field in description database-dependent.

This is already possible. Note that I changed the wording of the
definition of type objects (the parts you quoted). In mxODBC for
example I provide all the different SQL data type codes (as integers)
in the description field; the type objects are of the form:

# Helper for coltypes
class _dbiSet:
    def __init__(self,*values):
	self.values = values
    def __cmp__(self,other):
	if other in self.values:
	    return 0
	if other < self.values:
	    return 1
	    return -1

# Note that tests like 'coltype is STRING' don't work, you have
# use 'coltype == STRING'.
DATE = _dbiSet(SQL.DATE)

# mxODBC doesn't support RowID columns; use cursor.specialcolumns() to
# find out which columns are best suited to uniquely identify a row.
# This object is not equal to any other object.
ROWID = _dbiSet()

> 2) Provide a set of truth functions which take the place of comparing
> against fixed type code. For example, instead of:
>     if typecode == NUMBER: ...
> to:
>     if isnumber(typecode): ...

You can use the above approach to meet the DB API requirements
and still provide more detailed database dependent information
in the description field.

> Maybe I'm just not understanding this section, or the section doesn't
> really mean what it says:
> "A Cursor Object's description attribute returns information about each of
> the result columns of a query. The type_code must be equal to one of type
> codes defined below.
> "Note: The values returned in the description tuple may not necessarily be
> identical to the defined type codes, i.e. while coltype == STRING should
> always work, coltype is STRING may fail. This is necessary because the
> database interface may want to return more specific type codes than the
> ones defined below."

I'm not a too good writer and even worse have a mathematical
background, so maybe someone could edit the two sections to
clearify them...

> The last bit, what to do with NUMERIC/DECIMAL SQL fields (i.e.
> fixed-point)? Obviously converting them to integers is RIGHT OUT, and
> converting them to floats is probably not a good idea either. At the
> moment I just leave 'em as strings and let the application figure it out.
> This may need to just stay an open issue for awhile unless someone wants
> to come up with a fixed-point type for Python (perhaps a wrapper around
> long?).

mxODBC converts them to Python floats; but you're right: a
fixed point type a la the one that Tim Peters posted on c.l.p
written in C wouldn't be a bad idea (it could then also be used
for monetary values).

For now, I think floats are the way to go: at least they preserve
the fraction part.

Marc-Andre Lemburg                               Y2000: 282 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :