On Jan 3, 2009, at 9:34 AM, Dusty Phillips wrote:
>
>
>
> 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?
yeah this is why we dont rely on cursor.description for type
information in most cases (we do it only for the case of Oracle LOB
objects). The TypeEngine subclasses do have a
get_dbapi_type(dialect) method so once you have your dialect loaded
(this is engine.dialect) you could work with that, but this doesn't
solve the issue of incomplete type information coming back from
DBAPI. In general, I haven't noticed that DBAPIs are implementing
more type singletons beyond what the spec provides (i.e. those 6 types).
While it would be more tedious in your case, you could potentially
take the approach SQLA does, which is identify the types at the SQL
statement level by converting them to use the text() construct, which
takes a 'typemap' parameter.
the other question is why do you need the typing information if the
application has been working so far without it ?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
