質問: * 疑似コードぐらいの粒度では、rails の `db:migrate`, `db:reset`, `db:setup`, `db:migrate:reset` は、それぞれどのようにふるまっていますか? * その挙動がまとまっている資料はありますか?
回答: データベースに schema_migration というテーブルが造られて 成功したマイグレーションファイルの数字の部分(YYYYMMDDHHMMSS)が記憶されていて db/migrate ディレクトリと比較して未実行のマイグレーションを検出してます なので 1. 一度適用した MigrationFile を削除した(してしまった場合) 何も起きません DB側にのみ履歴が存在しますが特にエラーにもなりません 2. データベースの構築に使われていない MigrationFile が db/migrations にまぎれこんでいた場合 履歴にないので当然実行されます > > db:migrate, db:reset, db:setup, db:migrate:reset は、それぞれどのようにふるまっていますか? > > > その前に schema.rb というのがあってはマイグレーションが成功したときに更新されます 最後に成功したスキーマダンプファイルのようなものですね **db:migrate** DB の状態を正として未実行のマイグレーションファイルだけを適用します すでに適用済みのマイグレーションファイルを変更していても反映されません **db:migrate:reset** マイグレーションを正として すべてのテーブルをドロップしてマイグレーションをすべて再実行します この2つはマイグレーションファイルのみを見ていて schema.rb はみません(更新はします) **db:reset** schema.rb を正として すべてのテーブルをドロップして schema.rb の状態にテーブルを再作成します **db:setup** 最初にしか使ったことがなくて自信がないんですが データベース作成スキーマ変更シードデータ投入だけ行うんだと思います 既にDBが作成されてる場合エラーで止まるのかスキーマ更新をやるのかわからないですが この2つはマイグレーションは見ずに schema.rb だけを参照します 基本的にどこか1つの環境にでも実行したマイグレーションファイルは変更してはいけない スキーマを変更したいときは修正マイグレーションを作る という運用さえ守ってれば初回 setup とあと db:migrate だけでおかしなことはおきないはずです こちらによると db:migrate:reset = db:drop + db:migrate db:reset = db:drop + db:setup db:setup = db:create + db:schema:load + db:seed ということみたいです db:schema:load は force:true をつけると drop and create つけなければ create だけですでに存在する場合は already exist エラーになるようです なのでやはり db:migrate 以外でスキーマ変更をすると テーブル再作成になってレコードも消えるので注意