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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
