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

[Federico Di Gregorio]

Il gio, 2004-01-08 alle 11:58, M.-A. Lemburg ha scritto:
[snip]
> > 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.

agreed.

[list snipped, see previous mail :) ]

> 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.

maybe i used the wrong rapresentation (inheritance tree). by inheritance
i just mean that if the type_code x from the .description is compared
with STRING and CHAR the following holds true:

x == CHAR implies x == STRING  
x == STRING does not implies x == CHAR

this is just to make sure that old code comparing x with STRING still
works and that new code has more types available. if mxODBC exports CHAR
as an integer constant, the two equations above are _still true_.

now, by not requiring a specific kind of object for object types but
just a generic "object type", i think you're safe by having two kind of
object types: type(STRING) and simple int. or maybe, my two other
proposals are better, see below. 

> 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.

or we can ask for this *to be* the case :) [it makes sense to me, even
if it complicates the coding of the type objects a little bit]

> 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 ?

i think we should have requested, a long time ago, developers to not
pollute the module namespace but use a sub-module. here's another little
proposal:

  1/ all the module-level objects specified by DBAPI-2.0 should be 
     duplicated inside a sub-module, named 'dbapi' (or a dictionary?); 
     i.e.,
     
       mxODBC.STRING -> mxODBC.dbapi.STRING
       mxODBC.connect -> mxODBC.dbapi.connect

  2/ the old DBAPI-2.0 names should not be removed from the top-level
     module, but new objects are added only to the new 'dbapi' 
     module/dictionary.

this effectively add a safe namespace for future DBAPI additions.

-- 
Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
  Qu'est ce que la folie? Juste un sentiment de liberté si
   fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://mail.python.org/pipermail/db-sig/attachments/20040108/63182078/attachment.bin