[DB-SIG] Controlling return types for DB APIs

Robert Brewer fumanchu at amor.org
Tue Apr 17 22:24:07 CEST 2007


Art Protin wrote:
> Our database system has an nearly unbounded set of types.
> The types have two components, say a major and minor,
> or a main type and subtype.  The main type "STRING" alone
> has 65535 subtypes (one for each allowable size).
> Other main types may a few subtypes or even no subtypes
> Some of the subtypes make a major difference in the
> conversion function behavior (like those for DATE)
> and some make nearly none. My conversion routines are
> called based on the main type but need both the data
> value and the subtype as arguments.  Do any of the other
> systems have such a multi-level type scheme as this?

Geniusql does, but it's implemented by using classes to represent each
"main type" and instances (with varying attributes) for each subtype.
Each Column object gets its own DatabaseType instance (and so does each
expression when generating SQL).

For example, the firebird.py provider supplies a concrete VARCHAR class
(a subclass of the abstract dbtypes.SQL92VARCHAR class), and instances
of that class can have a "bytes" attribute anywhere from 1 to 32767 (the
default is 63):

    class VARCHAR(dbtypes.SQL92VARCHAR):
        synonyms = ['CHARACTER VARYING', 'CHAR VARYING', 'VARYING']
        max_bytes = 32767
        _bytes = 63


Given sufficient parameterization, there's usually no need to statically
model all 65535 STRING types in systems like these.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org


More information about the DB-SIG mailing list