On May 7, 2012, at 7:06 PM, Stefan Urbanek wrote: > > > >> 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. > > Table is not a view, right. On the other hand, views are quite useful and in > analytical domain they are being used quite a lot. The analytical data are > mostly read-only during their use, therefore I see no problem with treating > VIEWs as read-only TABLEs in this case. I would definitely not drop view > reflection from the library, as it is makes building another kinds of > abstractions/tools (besides ORM) much more easier.
oh no argument there, SQLA should support views better, with their own object called a View. We have all the reflection logic, we have a recipe, nailing down a full feature spec is straightforward. Someone needs to express an interest in establishing a behavioral spec that makes sense, given how creating a view works, reflecting, etc. -- 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.
