🐭

途中でmigrateいじる時の注意点

2024/07/20に公開

Rails

今回起きた事と学んだ事

今までの自分のやりやすいやり方のみを使ってmigrateを変更してきたんですね。
まぁそれで痛い目見ました。けど別に間違ってるわけではないからどっちも記載しよう。

直接migrateファイルを書き換える方法

今までやってきた方法です🕊️

rails db:migrate:status
rails db:migrate:down VERSION=statusで出てきた数字
rails db:migrate:status

これでちゃんと『up』から『down』になってたらmigrateファイルを書き換える。
書き換えたら

rails db:migrate
rails db:migrate:status

これでこれでちゃんと『down』から『up』になってたらOK！

今回起きた事

本番環境にデプロイ後railsエラーが出て確認したら返信機能のためにmigtretで付け足した『parent_id』を出力するページで『parent_idが無いよー』って。。。。
ちゃんとmigrateしたから本番環境でも下記のコード打ったしなんで...???となりまして。

bundle exec rails db:migrate RAILS_ENV=production

前回のデプロイの時にしたコメントが残ってたから引っかかってて、まぁそれは当たり前か。と思って今回は奇跡的に管理者側でコメント消せる仕様にしてたからそれ消したらいいんかなーと思ったけど、そうじゃない場合もあるよなーって思って、、

今回の解決方法と未然予防

まず今回は直接書き換えてしまってるのでssh上でdownさせてーupさせる流れで直そうと思ったんでですが

rails db:migrate:down VERSION=status RAILS_ENV=production

したら、エラーが出ました。
理由はdownさせるとか以前にpullしてきて内容が変わってるから。
cloud9でもdownさせる前に書き換えてそのままdownしたらエラー出るから当たり前のエラー。。。
今回はメンターさんがssh上で一回追加部分をコメントアウトしてdownさせてコメントアウト消してmigrateして直して下さいましたが、自分じゃできなかったな。と。。（:wqのやつ復習せな。。）

未然予防

そもそも直接書き直すのは推奨されてないらしいです。
理由はいくつかあるけど
１.どのカラムがいつ追加されたのかを簡単に追跡できるから
2.ロールバックの容易さ
3.データの安全性/データの損失や予期しない変更を最小限に出来る。
4.デプロイの安全性/既存のマイグレーションファイルを変更すると、実行済みのマイグレーションと新しい変更が一致しなくなる可能性があります。これにより、データの損失やデータベースの不整合が発生するリスクがある。

今回は４っぽいな🐿️

解決方法は、シンプルに新しいmigrateファイルを作成する方法がいいみたい🦩

今までもこのやり方は知ってたけど、、自分の性格的に、、同じページに全て書いてて欲しいんです、、
何個も開いて直すのが嫌だ。このページはこのページ直せばどうにかなる！！！がいい、、、、
(共通テンプレートも同じ理由で出来るだけ使いたくない)
今回も調べた時にほとんどの記事がこのやり方だったのに自分の頑固さゆえに強行突破してエラーにぶち当たりましたっと。🦫笑

メンターさんに教えてもらった記事

例

rails generate migration AddAdminToUsers admin:boolean

例

class AddAdminToUsers < ActiveRecord::Migration[6.1]
  def change
    add_column :users, :admin, :boolean, default: false
  end
end

rails db:migrate

ってやると過去のmigrateを変更するわけじゃ無いからエラーが起き辛いらしいです。

感想

まぁ結局過去のデータはリセットしなあかんのやろうけど、無駄なエラーを防げるならそっちでやったほうがいいなって。プログラミングってやり方が１個じゃ無いからこそ柔軟性持ってないとダメだなって実感した出来事でした。
（けどviを練習するためにはいいのか...???）