On May 7, 2012, at 6:09 PM, Stefan Urbanek wrote: > > p.s.: On the other hand, Table.is_view might be a good flag - to maintain > consistency with the fact that Table() can reflect a view. However, I am not > sure how does that fit into overall design of the library.
the reason is that it's a partial, broken API: t = Table("myview", metadata, Column(...), Column(...), # ... is_view=True ) metadata.create_all() ...to which we get, what exactly ? a view is not just a bunch of columns, you need the whole view definition. similarly: mytable = Table("someview", metadata, autoload=True) assert mytable.is_view mytable_2 = mytable.tometadata(othermetadata) othermetadata.create_all() -> same thing ! how do we do a CREATE ? is the whole view definition present ? do we have round trip tests for all that ? can I reflect a view from Oracle and recreate on SQLite ? the answer is: absolutely not. It would require that we can fully parse SQL, intelligently enough even to translate it into another platform, which is not just out of scope, it would be a vastly complicated process. Hence the whole thing stays as a recipe, and also why you're finding it awkward that you'd like to emit DROP for views that you've reflected; the "view reflection" use case was at most intended as a read only use case. I'm not 100% sure how "view reflection" even got into the library, to be honest, as it really doesn't belong in Table. a Table is not a view. -- 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.