On Aug 9, 1:42 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> On Aug 9, 2009, at 1:24 PM, allen.fowler wrote:
>
> > So, just to clarify:
>
> > At this point in time, can SQLAlchemy be used to define and query
> > simple VIEWs in a database agnostic manner?
>
> > And if not, is this a feature that is slated for addition any time
> > soon?
>
> CREATE VIEW is almost identical across backends and can be achieved
> like this:
>
> someselect = select([table.c.foo, table.c.bar])
> eng = create_engine('...')
> eng.execute("CREATE VIEW foobar AS %s" % someselect.compile(eng))
>
> then build yourself a Table with columns representing the view.
>
> its easy enough to build a CreateView DDL() construct in 0.6 to do
> this, i.e.
>
> eng.execute(CreateView("myview", someselect))
>
> I'd consult the sqlalchemy.ext.compiler docs for how to do this.
>
> as a builtin I'm uncomfortable since it implies adding a View() object
> to schema which raises lots of thorny questions like "what if I
> construct an INSERT against the view ?" " what about materialized
> views?" , "what if I join my View() to the underlying Table() ?" etc.
I am still using 0.5, and am not familiar with "below ORM" usage of
SQLAlchemy, but I think I get the idea.
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 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?)
Essentially, this simple case is just a pre-packaged select statement
upon which further refining select queries can be run. The reason for
placing it in the DDL/ORM would be to ensure that: 1) It is clean to
implement at the Python level, and 2) That abstraction happens at the
DB level for both performance reasons and consumption by non-
SQLAlchemy readers.
I imagine that this would solve a great many use-cases for VIEWs in
smaller projects where SQLAlchemy's coolness is already so addictive.
Do you think such a solution is feasible?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
