[DB-SIG] Type code mappings: expanding the type objects
Federico Di Gregorio
fog at initd.org
Thu Jan 8 06:25:53 EST 2004
Il gio, 2004-01-08 alle 11:58, M.-A. Lemburg ha scritto:
> > 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.
[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
1/ all the module-level objects specified by DBAPI-2.0 should be
duplicated inside a sub-module, named 'dbapi' (or a dictionary?);
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'
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
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
More information about the DB-SIG