initialize_column_rename does not capture view in schema.rb
martinstreicher opened this issue · 4 comments
initialize_column_rename uses a view to facilitate the column name change. However, views are not dumped to db/schema.rb. Hence, if you commit db/schema.rb and use rake db:drop db:create db:schema:load, the resulting database won't work because it is missing the view that stands in for the original table.
This is a problem. It is especially problematic if an environment like CI uses db:schema:load and not migrations to initialize its database. (db:schema:load seems to be the norm for CI environments.)
You can workaround the problem by not committing the db/schema.rb in the interim, using db:schema:load and then running migrations, but this is confusing and error-prone.
The best solution is the addition of the scenic gem to dump views into db/schema.rb.
I can provide a PR if you concur this is the best approach. I have tested this solution locally and it works like a charm with views and schema dumps created in tandem with the use of online_migrations.
I suppose the other option is to take the code from scenic responsible for dumping views and add it to this gem, if you don't want to pull in all of scenic.
Thank you for opening an issue. Another solution is to use structure.sql.
I am not in favor of making scenic a dependency of this gem. Provided that there are other db view-related gems someone would decide to use instead of scenic.
But I am on for the README update suggesting the use of structure.sql or something like scenic for schema.rb users.
Feel free to contribute, if you would like to.
Yes, switching to structure.sql works well.
I looked at the Scenic code used to dump views. It would not be difficult to extract it and add it to this gem. However, if someone were to add scenic, the views might be output twice in the schema dump.
However, that may be an unusual case. I would argue that dumping the views in the schema is a valuable addition to this gem. Otherwise, people will have to switch to structure.sql. It does make this gem more standalone.
Up to you.
Added a note to the readme - f9eb505.
I do not want to introduce the logic for dumping views (at least for now), because it is quite some code and it is possible to have API compatibilities issues with the existing gems (like scenic), e.g. this gem's create_view will have a different signature than create_view from scenic.