migrateするときに確認しておきたいこと。
当たり前すぎることをめも。
###マイグレーションファイル作成
#####基本的なコマンド
bundle exec rails generate migration [処理+テーブル名]
[処理+テーブル名の例]
あるテーブル(TestTables)
- create:CreateTestTables
- カラム(test_column)追加:AddTestColumnTestTables
- drop:DropTestTables
…など。
※追加の場合は「AddColumn」とするのが一般的？
あといっぱい追加するときはどうするんだろう？
(4つぐらいカラム追加したときのメソッドがカオス)
なんて疑問は残しつつ。
#####AddColumn自動化コマンド
bundle exec rails generate migration Add[カラム名]To[テーブル名] [カラム名]:[型]
[Add[カラム名]To[テーブル名]の例]
あるテーブル(TestTables)
- カラム(test_column)追加:AddTestColumnToTestTables
###マイグレーションファイル編集
マイグレーションファイルを編集する。
upメソッドに今回実施したい内容、
downメソッドにそれを打ち消す内容を記載する。
記載の仕方はリファレンス参照。
主に迷うポイントは下記。
- t.timestampsってなんだよ
⇒create_at、updated_atを作成 - lock_versionってどうすんだよ
⇒t.integer :lock_version, :default => 0
###マイグレーションを試す
開発環境で試す。目的としては本番環境で問題なく動作することを確認しておきたい。
できればこの時点でデータバックアップを取得しておき、いつでも戻せるようにする。
bundle exec rake db:migrate
bundle exec rake db:rollback
※rollbackは1つ前にしか戻れないので、複数マイグレーションファイルがある場合は注意！
ファイル数分rollbackするか、downメソッドで試すこと。
但し、schema_migrationsテーブルはmigrateコマンド実施前に戻る模様。
⇒この時点でバックアップを取得していた場合、一旦リストアして本当に戻るか確認する。
bundle exec rake db:migrate
一旦rollbackしてdownメソッドが正常動作することを確認する。
この時点で全ての環境(test、production)には反映せず、マイグレーションファイルが確定した時点で他の環境に反映する。
(何回もマイグレートするのがかったるいから、なるべく確定後反映が望ましい気がする。)
bundle exec rake db:migrate RAILS_ENV=test
bundle exec rake db:migrate RAILS_ENV=production
###マイグレーションを消す
作ったけどいらなくなったマイグレーションファイルを消したいとき。
うっかり消して整合性取れなくなってもやだなーみたいな。
bundle exec rails destroy migration [作ったファイルのクラス名]
###もしもうっかりrmしてしまった場合
[参考]
railsのrakeのmigrationファイルを削除しNO FILEとstatusに出た時の対処
###マイグレーションの履歴を確認する
履歴見れたら便利だよね。
そういうの戻れたらいいよね。みたいな。
bundle exec rake db:migrate:status
※ついでに | grep なんか使うともっと効率的に探せる。
bundle exec rake db:version
###マイグレーションファイルのup/downを動かす
昔作ったカラムやテーブルがやっぱりいらなくなった。
前に作ったマイグレーションファイルのdownを使いたい。とか。
rollbackじゃなくてupメソッドだけ使いたい。とか。
そういうとき。
bundle exec rake db:migrate:up VERSION=[バージョン番号]
bundle exec rake db:migrate:down VERSION=[バージョン番号]
バージョン番号はマイグレーションファイルの先についている数字列。
※ちなみにdestroyしちゃった後、git checkoutして戻したファイルでも問題なく動く。(動いた)
###change
add_columnならup/downを自動でやってくれるらしい？
※聞いただけ。未調査＋未実施。