On Jan 1, 12:29 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> the internal location where TypeEngine types that were known before
> cursor.description was fetched is result.context.result_map. this
> only applies to SQL expression constructs though. In the case of
> connection.execute("some string"), we dont know anything about the
> types except for what's in cursor.description.
Thanks, I understand now. I am indeed using connection.execute(string)
for these connections; the idea is to support legacy calls directly
while I convert the rest of the system to use the sqlalchemy ORM.
It seems my only two options are to create a lookup table of
cursor.description type values to strings identifying the database for
each dbapi I want to support, or to introspect the values by comparing
to the dbapi2 type singletons.
The latter is undesirable as there are only six dbapi2 types and
numerous types for the underlying database. The former mapping idea
seems like a common enough requirement that "somebody must have done
it" -- thus my assumption that something like it must exist somewhere
in sqlalchemy already. I really feel like I'm in a "You're doing it
all wrong" situation; would somebody else approach the problem
differently?
In addition, neither of these approaches works with sqlite, as their
dbapi module breaks PEP249 by not supplying any type information. Are
there any special tricks to work around this?
Thanks,
Dusty
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
