[DB-SIG] Type code mappings: expanding the type objects

[M.-A. Lemburg]

Federico Di Gregorio wrote:
> another list, amended with marc's comments. if everybody agrees on this
> list i'll go on and write the new paragraph for the PEP document.
> 
> changes:
> 
>   1/ removed TEXT in favor of LONGVARCHAR;
> 
>   2/ removed MONEY (DECIMAL is the name for fixed point), backends
>      providing currency information will define a sub-type of decimal,
>      right?
> 
>   3/ BOOLEAN is under NUMBER (this will probably give some problems to
>      postgresql and other db using 't' and 'f' but there is really no
>      simple solution and Python *do* use 1 and 0 for True and False (at
>      least untill 2.3)
> 
> i tought about using three or four levels:
> 
> STRING
> |__VARCHAR
>    |__LONGVARCHAR
> 
> but i really don't see any improvement. the two-level hierarchy is there
> for _backward compatibility_, not for organizing the tree. does this
> make sense?

Not really: LONGVARCHAR is a completely different beast than
VARCHAR. It is stored differently, usually has different properties
in the database and switching from VARCHAR to LONGVARCHAR is
not always easy.

> here is the list:
> 
>  STRING
>  |__CHAR
>  |__VARCHAR
>  |__LONGVARCHAR
>  |__TEXT
>  |__WCHAR
>  |__WVARCHAR
>  |__WLONGVARCHAR
>  BINARY
>  |__VARBINARY
>  |__LONGVARBINARY
>  NUMBER
>  |__BIT
>  |__INTEGER
>  |__SMALLINT
>  |__BIGINT
>  |__FLOAT
>  |__DOUBLE
>  |__REAL
>  |__DECIMAL
>  |__COMPLEX
>  |__BOOLEAN
>  DATETIME
>  |__DATE
>  |__TIME
>  |__TIMESTAMP
>  |__INTERVAL
>  |__TZTIME
>  |__TZTIMESTAMP
>  ROWID

A question: while the inheritence scheme makes sense for the
implementation of the type objects, is it necessary to have
them decend this way ?

I'm asking because mxODBC has for many years exported
symbols under these new names mapping to the underlying
SQL integer constants. Changing these to type objects will
break code.

Now, the DB API only asks that these type objects must compare
equal to the entries in the .description field. If e.g. CHAR
is an integer, it would still compare equal to the .description
field, but these would be no inheritence from STRING.

OTOH, STRING has always been a special type object, so
comparing STRING and CHAR will result in a true value
in mxODBC. If CHAR is implemented as type object this would
no longer be the case.

Perhaps we ought to be more careful with adding globals
to the module scope in the DB API spec. Possible work-arounds
are e.g. STRING_CHAR, STRING_VARCHAR, etc.

What do you think ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 06 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::