0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

マイグレーションファイルから Model を直接触るのはやめて欲しい

Last updated at Posted at 2020-10-12

何が起こったのか

開発環境で新たにDBを作成。

お約束通り、

$ rails db:create
$ rails db:migrate

大量のマイグレーションファイルを一気に migrate しようとしたその時、事件は起こった。

PG undefined column hogehoge ...

的な感じで、スッと通らない🧐
嫌な予感がする。

なになに。。。。

マイグレーションファイルから直接 Model にアクセスしていたんです。

migartion_file
...

Hoge.delete_all

...

みたいな感じでモデルに対して直接操作を行う処理が書かれていた😓

そのマイグレーションファイルは過去のものであり、その当時はそのモデルがあったのだろうが、今現在のソースコードには存在しない。
当然、 そんなモデルは無いよ と怒られたりする。

こんな感じで直接 Model に対して処理を行っているマイグレーションファイルが散見された。
結果 migrate を通すのにものすごく苦労し、過去のマイグレーションファイルにも手を入れなくてはいけなくなった。

マイグレーションファイルってそういうものなのでしょうか?
いいえ、違うはずです。

どうすれば良いのか

マイグレーションファイルは、後々どんな人が開発に入ってきてもしっかり rails db:migrate が通るように積み上げていきましょう。

ファイル数が増えるのは仕方ありません。大事なのはしっかり通るかどうかです。
おそらく当時の開発者もモデルに対して処理を書いているのは分かっていたはずで、データメンテナンスがしたかったのだと思います。

既存データのメンテナンスはマイグレーションファイルでやらないで、rake task を作成するとか他にもやり方があったはずです。

自戒も込めて、マイグレーションファイルに関して気をつけるべきことを書いておきます

  • マイグレーションファイルを追加した時には、 rails db:migrate:redo を習慣づけて redo が通ることを確認する
  • 古いマイグレーションファイルを後から書き換えない(見栄えは悪いが単純に積み上げていくのがベストプラクティス)
  • データメンテナンスはマイグレーションファイルの中で行わない(rake task を作ったり rails console から手動やったり他の方法がある)

Model は単なる ruby のクラスに過ぎません。
それは今後名前が変わるかもしれませんし、データの持ち方も変わるかもしれません。

マイグレーションファイルの中からモデルを直接触るのはやめましょう😭


どなたかの役に立てば幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?