[DB-SIG] Controlling return types for DB APIs
Michael Bayer
mike_mp at zzzcomputing.com
Tue Apr 17 19:53:31 CEST 2007
On Apr 17, 2007, at 10:51 AM, Art Protin wrote:
> Yes, something nice and simple, like a dict using the string name
> of the DBMS native
> datatype as the index. However, this might not work out after
> all. 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?
>
im not following this thread so closely, but SQLAlchemy does have a
configurable type system which can represent both the "major" type as
you call it, plus any number of arguments for each type (which youd
call the "minor" type), for any given result set column. The "major"
part is represented by the particular subclass of TypeEngine used,
such as SLDateTime ( a date time type as represented in SQLite), and
the "minor" part by the state of that particular TypeEngine instance
(such as the length of a string column, or its encoding).
Of course SQLAlchemy is a significant layer on top of DBAPI, so as
far as the "registry"-like functionality of what types map to what
columns, its achieved via the presence of Table objects which are
comprised of collections of Columns each with their own TypeEngine
instance. if DBAPI contained its own type-registry like system
(which would likely be per-connection, since thats the highest-level
object DBAPI provides which is still stateful with regards to a
particular database connection), SA could probably modify TypeEngine
to move its type-conversion code into this layer, instead of having
to piggyback the translation onto result set objects.
However i might suggest that this whole thread, "controlling return
types", perhaps be expanded to include "controlling *input* types and
return types", since to me (as well as to SQLAlchemy) being able to
send an arbitrarily-typed python object into a bind parameter is just
the mirror image of receiving a result column as an arbitrarily-typed
python object. I think it would be unfortunate if only one half of
the coin were addressed.
More information about the DB-SIG
mailing list