On Aug 9, 2009, at 5:36 PM, allen.fowler wrote:
> > > Still, though, it looses the auto generation capability via > drop_all()/ > create_all() vs. traditional tables and feels out-of-place along side > the rest of SQLAlchemy's slickness. I still have the job of documenting 0.6's features, but even in 0.5 any DDL() construct can be associated with MetaData as an event (this is in the 0.5 API docs). This can all be done in 0.5 using just DDL(), 0.6 will just provide a straighter user-definable path right through the entirety of SQLAs entire DDL generation process. > I do understand your concern about adding a View() object at this > stage. Perhaps it could be implemented by limiting it's scope and > thinking of a better word to describe what is needed since it is not a > VIEW in the full meaning of the word. (SimpleView? PreSelected?) All of the edge cases are what come about once I put the whole thing in core, and people start turning the crank further and further, expecting to see what "they expect" and then complaining when it doesn't work (i.e. they cease to be alchemists!). As a usage recipe, users assume responsibility for the limitations of the approach as well as its mechanisms. So here is that recipe: http://www.sqlalchemy.org/trac/wiki/UsageRecipes/Views . its 20 lines of public API save for one underscore method which I suppose we can make public (its just hard to explain, mostly). I think you'll see its pretty clean as a user recipe. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
