背景
データベースのテーブルに「カラムを追加して」とか「カラム削除して」とかお願いすると、なぜかできないって方がたまにいたりする。
なぜかなと思ってよくよく確認して見ると、
-
migrationファイルを編集して、rails db:migrateするだけだったり -
schema.rbを編集するだけだったり
みたいなことがあるようです。
なので、データベースのテーブルなどが生成、編集されるフローをまとめてみることにしました。
データベースのテーブルなどが生成、編集されるフロー
簡単な流れを書くと以下のとおりです。
-
database.ymlの作成(データベースの設計図に当たる) -
rails db:createの実行(database.ymlを元にデータベースを作成) -
migrationファイル(xxxxxxxxx_create_blogs.rbみたいなやつ)の作成(テーブルの設計図に当たる) -
rails db:migrateの実行(migrationファイルを元にテーブルを作成編集) - 4の結果が
schema.rbに反映される
では順を追って説明していきます。
database.ymlについて
これはrails newで自動作成されるので、あまり意識しませんよね。
実はdatabase.ymlを元にデータベースが作成されているのです。
rails db:createについて
これはdatabase.ymlを元にデータベースを作成するコマンドです。
テーブル云々には関係無いです。
つまりアプリケーション作成において、1度実行するだけでよいコマンドです。
（まれにDB壊してもう一度作りたいときとかは2回目を実行したりもします）
migrationファイルについて
これはscaffoldとかrails g modelとかで自動生成されたりもします。
ただ、migrationファイルはテーブルの設計書にすぎないです。
rails db:migrateについて
これはmigrationファイルを元にテーブルを作成編集するコマンドです。
つまり、migrationファイルを作っただけではテーブルは変化しません。
rails db:migrateを実行してテーブルが変化します。
ここ重要！
さらに、一度設計書として参照されたmigrationファイルは、次回以降のrails db:migrate参照対象からはずれます。
つまり、一度作ったテーブルを変更するには、新しいmigrationファイルを作成し、rails db:migrateを実行する必要があるのです。
※roll backなどを使う方法もありますが、ここでは割愛します。
schema.rbについて
rails db:migrateの実行結果が反映されるファイルです。
まとめ
- 一度作ったテーブルを変更するには、新しい
migrationファイルを作成し、rails db:migrateを実行する必要がある -
schema.rbは結果を反映するだけ。編集してもテーブルが変化するわけではない。schema.rbを削除してもアプリは動くのです。
※ただ、schema.rbは他の使いみちがあるので、削除はおすすめしません。