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 · 13 comments

Comments

Projects
None yet
8 participants
@josevalim
Member

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

This comment has been minimized.

Show comment
Hide comment
@OvermindDL1

OvermindDL1 Nov 16, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@lukerollans

lukerollans Nov 22, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@joshuataylor

joshuataylor Nov 22, 2016

What about materialized views?

joshuataylor commented Nov 22, 2016

What about materialized views?

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Nov 22, 2016

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@eniolopes

eniolopes Nov 25, 2016

Contributor

can i work on this one?

Contributor

eniolopes commented Nov 25, 2016

can i work on this one?

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Nov 25, 2016

Member

Yes, please!

Member

josevalim commented Nov 25, 2016

Yes, please!

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth 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.

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

This comment has been minimized.

Show comment
Hide comment
@michalmuskala

michalmuskala Dec 5, 2016

Member

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
"""
Member

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

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth 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.

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

This comment has been minimized.

Show comment
Hide comment
@roehst

roehst Feb 21, 2017

Contributor

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!

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Feb 21, 2017

Member

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. :)

Member

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

This comment has been minimized.

Show comment
Hide comment
@roehst

roehst Feb 21, 2017

Contributor

@josevalim Nice, I will try that. Tks

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Aug 2, 2017

Member

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.

Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment