Railsにおいてマイグレーションファイルの扱い方を理解したい

Question

前提・実現したいこと

現在Railsを勉強しております。
もともとJavaエンジニアであり、その差分に戸惑っています。
なかでもなかなかマイグレーションファイルの扱い方がしっくりきていません。

結論から言うと、以下が知りたい点です。
・基本的に、マイグレーションファイルは実行後に、変更して、もう一度同一ファイルを実行したりはしないでしょうか？つまり１ファイルに付き１回の実施のみでしょうか。
・もし新たに変更を加える際は、基本的に、新たにマイグレーションファイルを追加して、そのファイルを実行して使うのでしょうか？

マイグレーションファイルは、テーブル変更のファイルといった認識ですが、
そのファイル自身をテーブル変更の度に編集し、実施するのではなく、
時系列で管理するため、１ファイル１変更で、さらに更新したいときは新たにファイルを作成する認識であっているかを確認したいです。

試したこと

自分でも調べ、以下が私のマイグレーションファイルの認識です。
・Rubyで書かれた テーブルの設計図
・rails generate migration クラス名で生成できる。この場合は自分でマイグレーションファイル内に記述する
・rails g model モデル名 フィールド:型:(unique|index)でモデル生成と同時に自動生成できる
・rails db:migrateすることでマイグレーションファイルの内容をDBに反映できる
・ファイルのプレフィックスが生成した日時となり、自動的に管理できる
・やはり基本的に１ファイルに付き１変更？（←知りたいこと）

なかなか調べてもその点が明確になっていないので、この認識で基本的に合っているかを有識者の方に確認したいです。
よろしくお願い致します。

Answer 1

やはり基本的に１ファイルに付き１変更？

基本的にはそうです。
まぁ複数のカラムを追加するといった事も場合によってあるでしょうけど。

補足

開発時点では、マイグレーションファイルを何度も書き換える事が多いです。
というのも、テーブル定義をできるだけ一箇所に集約したほうがコードの可読性の観点でも良いからです。

なので、

bin/rails db:drop
bin/rails db:create
bin/rails db:migrate
bin/rails db:seed

を何度もやる事になるでしょう。
少なくともうちはそうしています。

開発メンバーが複数いるのでgit pullした時にマイグレーションファイルが更新されていたら
DBをクリアする必要があるからです。
面倒ですがこうしないと、開発中なのにカラム追加やカラム削除、インデックス追加だけのマイグレーションファイルが量産されてしまいます。
ぶっちゃけそっちのほうが困ります。
開発中はテーブル定義は一箇所にまとまっててくれないと把握が面倒です。
テーブル定義も作りながらだんだん固めていくスタイルのせいでもあります。
アジャイル的な。
なので、開発中はガンガンテーブル定義を書き換えて良い事にしています。
マスタデータはdb/seeds.rbで登録できるようにしておけばいいし、テストデータが必要なら各自でrails runnerで登録できるように工夫しておけばいいです。

本番リリースされて運用が開始された後は、カラム追加やインデックス追加などの差分のマイグレーションファイルを作る事になります。
当然ですが、既存のマイグレーションファイルを修正する事はしません。

Comments

[k499778]

回答いただきありがとうございます。
マイグレーションファイルの認識が明確になったと思います。
自分自身の認識がある程度間違っていなかったことがわかってよかったです。

また補足の部分もすごくためになりました。
たしかにテーブル定義がまとまっていないと把握しづらいですもんね。
リリース後は変更ごとにファイルを生成する必要がありますが、リリース前は、そのようなやり方でまとめれることができると知れてよかったです。納得です。ありがとうございます！