はじめに
チームでアプリケーション開発をしていて、データベースを設計をしていくと
GitHubにpushしたマイグレーションファイルの取り扱いについていろいろと振り回され
学ぶことが多いと思います。
そのときに参考にさせていただいたのが、こちらの記事でした。
GitHubにpushしたmigrationファイルは安易に修正してはいけません
本記事は、テーブルを統合することによって不要になったモデルファイルを消すときのお話です。
2つのテーブルを１つに統合することになった
開発を進めていくと、２つのテーブルを１つに統合することがありますよね。
AとBの２つをAに統合して、Bが不要になったとします。
Bテーブルを削除するには、新たにdropするマイグレーションファイルを追加するとして、
Bモデルを削除するには、消し漏れを防ごうとして、「rails d(estroy) model B」を実行したくなりますが、やってはいけません。
なぜ？
Bモデルのファイルと一緒に、Bテーブルをcreateするマイグレーションファイルも
削除されるため、マイグレーション履歴が壊れてしまうからです。
実際にやらかしてみた
※ここからは、Aテーブルを「hoge」、Bテーブルを「test」で表現します。
testモデルを消したいので、「rails d model」コマンドで削除したら、こんな事になりました。
% cd アプリケーションのパス
% rails d model test
Running via Spring preloader in process 36020
invoke active_record
remove db/migrate/20200227115950_create_tests.rb
remove app/models/test.rb
invoke rspec
remove spec/models/test_spec.rb
invoke factory_bot
remove spec/factories/tests.rb
３行目のremoveに注目すると、__testテーブルをcreateするマイグレーションファイルが
削除されている__ことが分かります。
この状態でマイグレーションの履歴をみるとこうなります。
% rails db:migrate:status
database: hogehoge_development
Status Migration ID Migration Name
--------------------------------------------------
up 20200210112600 Create hoges
up 20200210115950 ********** NO FILE **********
up 20200211120823 Create fugas
up 20200211133456 Add Column hoges
up 20200211135601 Drop tests
Migration ID 「20200210115950」の名前が見事になくなっています。
このIDは、「test」テーブルを作成するマイグレーションファイルに当たります。
モデルを消したいだけなのに、必要なファイルまでもが消えてしまいました。
こうなってしまうと、後から参加するメンバーが git clone しても
マイグレーションの実行で失敗してしまい、データベースが構築できなくなってしまいます。
もちろん、マイグレーションの履歴を見た瞬間にあばばばばとなりました。
さあ、復旧しよう
削除したファイルがゴミ箱に残されていたのが幸いでした。
「20200227115950_create_tests.rb」を元の場所に戻すことで復旧ができました。
とにかく良かった(^^;
ではどうすれば良かったのか
「rails d model」コマンドでは消さずに手作業で対象となるファイルを消します。
今回は、モデルとRSpecテストの各ファイルを削除しましょう。
#モデルファイルを消す。
% cd アプリケーションのパス
% cd app/models
% rm test.rb
#RSPecファイルを消す。
% cd ../../spec/factories
% rm tests.rb
% cd ../models
% rm test.rb
ターミナルで消すのは面倒だという人は、VS Codeのエクスプローラーから削除するとラクです。
僕もこの方法で消しました。
まとめ
今のところは、不要になったモデル(とテストに関連する)ファイルは、手作業でしか消せません。
効果的な方法がありましたらコメントをいただけると助かります。