Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support views in migrations #1805

Closed
josevalim opened this issue Nov 16, 2016 · 16 comments
Closed

Support views in migrations #1805

josevalim opened this issue Nov 16, 2016 · 16 comments

Comments

@josevalim
Copy link
Member

@josevalim josevalim commented Nov 16, 2016

The idea is to introduce functions called view/1 and view/2 such that:

create view(:my_view, from(u in "users", where: u.type == :student))
drop view(:my_view)

create requires a query to be given to the view, drop does not.

We will also introduce a create_or_replace/1 function, similar to create/1, but mean to be used with views.

@OvermindDL1
Copy link
Contributor

@OvermindDL1 OvermindDL1 commented Nov 16, 2016

Definitely want that, I have a few view's in my system right now but I setup and tear them down via SQL.

@lukerollans
Copy link
Contributor

@lukerollans lukerollans commented Nov 22, 2016

Will be keeping an eye on this. The frontend to one of our biggest apps relies fairly heavily on views, would be very nice to manage them natively

@joshuataylor
Copy link
Contributor

@joshuataylor joshuataylor commented Nov 22, 2016

What about materialized views?

@josevalim
Copy link
Member Author

@josevalim josevalim commented Nov 22, 2016

@joshuataylor we can support a :materialized option in view/3 or a materialized_view/2 function as well. I will need to study the behaviour in different databases before deciding which one works best.

@eniolopes
Copy link
Contributor

@eniolopes eniolopes commented Nov 25, 2016

can i work on this one?

@josevalim
Copy link
Member Author

@josevalim josevalim commented Nov 25, 2016

Yes, please!

@hauleth
Copy link
Contributor

@hauleth hauleth commented Dec 5, 2016

I was just thinking about introducing it by myself. What would be useful with this one is:

  • triggers
  • functions

As it would allow us to create additional things that would be useful with views.

@michalmuskala
Copy link
Member

@michalmuskala michalmuskala commented Dec 5, 2016

We should carefully consider if we're able in any way to provide something more usable than execute(SQL).
I'm not sure I can imagine providing something more than

create function("""
some sql
""")

and I'm not sure I see advantage over

execute """
CREATE FUNCTION some sql
"""
@hauleth
Copy link
Contributor

@hauleth hauleth commented Dec 5, 2016

@michalmuskala there is one: autocreate down method for rollbacks. However there is only a little (if any) advantage of doing that. Maybe except allowing to reference function types using Ecto.Type.type/0 which would be handy.

@roehst
Copy link
Contributor

@roehst roehst commented Feb 21, 2017

Hi, I want to start contributing to Ecto (and Elixir in general) and I was about to suggest this feature. Is anyone working on it? Is it still in discussion? I am new to open source projects so forgive me if I don't understand part of the workflow on this. Thanks!

@josevalim
Copy link
Member Author

@josevalim josevalim commented Feb 21, 2017

I don't think there is someone working on it right now. If you want to start contributing on this area, maybe #1832 is a better starting point, for you to get acquainted with the codebase. :)

@roehst
Copy link
Contributor

@roehst roehst commented Feb 21, 2017

@josevalim Nice, I will try that. Tks

alesasnouski pushed a commit to alesasnouski/ecto that referenced this issue Jun 11, 2017
alesasnouski pushed a commit to alesasnouski/ecto that referenced this issue Jun 11, 2017
@josevalim
Copy link
Member Author

@josevalim josevalim commented Aug 2, 2017

We have stepped down from this feature because using Ecto.Query to generate views had unwarranted side-effects. A discussion of other approaches, which could be encapsulated in helpers that will be part of future Ecto versions, can be found in #1805.

@josevalim josevalim closed this Aug 2, 2017
@KristerV
Copy link

@KristerV KristerV commented Mar 30, 2020

Sooo, currently the only way is still execute()? I've already used the from() syntax to create my 20 queries, any way to put those into the execution string?

@josevalim
Copy link
Member Author

@josevalim josevalim commented Mar 30, 2020

@KristerV you can use Repo.to_sql to get those queries as SQL statements. But it is probably best if you still pass them as strings.

@KristerV
Copy link

@KristerV KristerV commented Mar 30, 2020

Yeah I realized, that your migrations need to be static (and not connected to any schemas or anything), so best is raw strings anyway. For future lurkers :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.