-
-
Notifications
You must be signed in to change notification settings - Fork 222
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
What are your thoughts on the 'schema_plus_views' gem? #74
Comments
We've talked about doing the same, but I have the same concerns as you. It boils down to the same reason you are discouraged from accessing external ActiveRecord models in your migrations - the underlying code can change or go away completely, leaving your migration in an invalid or incorrect state. I could perhaps see a generator that accepts a ruby string which is then @calebthompson thoughts? |
More broadly, on the Now that |
I don't know. I'm pretty happy with the gem as is. You guys did a great job making this. I looked at the pull requests for materialized views but I just don't have a need for them (selfish, I know). |
The ruby string thing in the generator is iffy. I rarely get complicated strings like that right the first try, and on the command line I doubt it would work. I do still like the idea of a to_sql thing though. What about an example in the README of generating the view in IRB with scopes, then printing the to_sql and throwing it in the view definition file (incidentally, this is how I'd recommend you do it). |
Our name is better we can't give up. |
This isn't a feature we're going to consider at this time. Thanks for the discussion, though. |
Totally agree! SQL statements in the schema show how the view's being built - especially important since it relies on other tables in the database. I've been using the gem for a couple of months now and am very pleased with it. |
Hey all, let me know if this is not the right place to bring this up.
Like thoughtbot's
scenic
gem, theschema_plus_views
gem gives the developer a way to create database views through the rails api and to capture those views in the app's schema file.One interesting difference is in its Creating Views section. You can create views through the
ActiveRecord
api.It gives the following example:
I can see an advantage and disadvantage. I can utilize the scopes and associations I've already defined on my models. I don't have to recreate them in a sql file. However, if scopes or
where
predicates change, two developers can have different views depending on when they run the migration.What do you all think?
The text was updated successfully, but these errors were encountered: