I work with the OP. The columns are correctly typed and the reflection code seems to work correctly with views that are directly selecting from tables. Its when a view selects from another view that we have problems with the type being lost.
Can anyone else say for sure whether it is supported to autoload a table object from an SQLite view? If it is, this would seem to be a bug. If not, I guess were are lucky it works in the first place. New feature maybe? Thanks. On Jul 21, 7:09 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote: > it is news to me that SQLAlchemy's table reflection code would even read a > SQLite "view" (and that sqlite had views, actually). Make sure your > view defines character based fields as "VARCHAR", "CHAR" or similar. > note that SQLite has a very casual notion of types so you can make up any > type names that you want. NUMERIC, DECIMAL, and REAL will reflect as a > SQLAlchemy Numeric, a type that by default returns python decimal values. > > guruofgentoo wrote: > > > In SQLite, I have a db view which selects from a second db view. When > > accessing this view as a sqlalchemy Table with autoload, the fields > > are being treated as Decimal. This raises an InvalidOperation > > exception when I attempt to access a varchar value. > > When I have a view selecting from table fields (tables created with > > sqlalchemy) instead of another view, this problem does not occur. Why > > is the type information being lost in multiple layers of views? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
