heroku上のアプリ からダウンロードしたデータをローカル(development)のDBに投入したところ、migration のバージョンが heroku上にあった物になってしまい、かつ、環境がプロダクションと認識されるようになってしまいました。
$ bin/rails db:rollback
rails aborted!
ActiveRecord::UnknownMigrationVersionError:
No migration with version number 201906********.
bin/rails:4:in `<main>'
Tasks: TOP => db:rollback
(See full trace by running task with --trace)
調べてみた所、migrationのバージョンの履歴は schema_migrations というテーブルに格納されていることが分かりました。
データベースを丸ごと投入したため、このテーブルも置き換わってしまい、DBに記録されているバージョン番号が現在Railsアプリにあるマイグレーションファイルの番号と一致しない状態になっていました。
参考: Ruby on Rails - マイグレーション履歴を削除して再実行したい|teratail
https://teratail.com/questions/176515
migration履歴はschema_migrationsテーブルに格納されているようですね
ではいっそ db:migrate:reset
してしまおうとすると、今度は「Production環境ではこの操作はできません」的なエラー。
$ bin/rails db:migrate:reset
rails aborted!
ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database.
If you are sure you want to continue, run the same command with the environment variable:
DISABLE_DATABASE_ENVIRONMENT_CHECK=1
bin/rails:4:in `<main>'
Tasks: TOP => db:migrate:reset => db:drop => db:check_protected_environments
(See full trace by running task with --trace)
でも確実にdevelopment環境のはず。もしかしてこの情報(productionかどうか)もDB上に保存されている?
こちらも調べてみたらまさにそうでした。
参考: Rails5でDBに自動生成されるテーブル、"ar_internal_metadata" とは何なのか - Qiita
https://qiita.com/EastResident/items/53c24340fd322758901f
"ar_internal_metadata" という見慣れないテーブルが存在している
Rails5から追加された新機能で、DBの不用意な削除を防止するための機能に必要なテーブルみたいです。
MySQL Workbenchでデータベースを見てみたら、 ar_internal_metadata テーブル、ありました。productionに置き換わってました。
今回は development 環境ということもあり、データを全削除しても問題なかったので
MySQLで appname_development のデータベースを丸ごとdropして、 bin/rails db:create
→ bin/rails db:migrate
し直しました。
これらの情報がDB上に保存されていることを知らなかったので、うっかり本番環境に接続してしまっていたかと焦りました。
(Railsアプリのどこかや環境変数で管理されていると思ってました。)
環境
Windows 10
Ubuntu 18.04.1 LTS (Windows Subsystem for Linux)
Ruby 2.5.3
Rails 5.2.1
MySQL 14.14
0 件のコメント:
コメントを投稿