私は、何百もの移行を蓄積したプロジェクトに取り組んでいますが、長期的にどうすればよいかわかりません。それらは何も害を及ぼさないと思いますが、増分移行のために大量の古いファイルを保持し、そのうちのいくつかは後で削除されるテーブルを作成するのは奇妙に思えます。
これまでのところ、3 つの可能性を見てきました。
放っておけ。彼らは何も傷つけていません。
それらを削除するだけです。新しい開発者はおそらく移行ではなくスキーマのロードから始めるので、これを行うことに大きな害はないと思います。
それらをすべて削除し、古いマージと一致するタイムスタンプで新しいものを作成し、スキーマから新しいマージを作成します。これは非常にきれいに見えますが、実際に誰が使用するかはわかりません。
私はそれらを削除する傾向がありますが、見逃している大きな落とし穴があるかどうか知りたいです.
私の意見では、プロジェクトのすべてのデータベース、特に本番環境が少なくともバージョン '201xxxxxxxx' になったらすぐに、そのバージョンより前の移行を削除しても問題ありません。それらは技術的に必要なくなりました。
その後、データベースの履歴で考古学をプレイしたい場合は、バージョン管理システムを引き続き使用できます。
たとえば、 Gitでは、次のコマンドを使用して過去を簡単に確認できます。
git log --name-only db/migrate/ #to list commit involving migrations + migration filename
git show xxxxx db/migrate #to see the code of commit xxxxx's migration(s)
または、上記のコマンドを使用して、のリポジトリ履歴をschema.rb参照し、コミットを特定して、対応する移行コンテンツを表示できます。
軽量化db/migrateしてバージョン管理を使用したい場合は、少しクリーンアップします。
ブラウズしやすいので、移行履歴全体を直接利用できる方が便利だと思う場合は、オプション 1 を使用します。
注: 古い移行が現在のアプリケーション コードでは意味をなさない可能性が非常に高いです。たとえば、一部の移行では、存在しなくなったクラスまたはメソッドが参照される場合があります。バージョン管理を使用して、移行が作成された時点でアプリケーションをチェックアウトすることで、混乱を避けることもできます。
十分な規模のプロジェクトに十分長い間取り組んでいると、これらの余分な移行すべてを軽蔑して見て、どれほど多くのものが存在するのか疑問に思う時が来るでしょう。
あなたは自分自身に「それらを削除してください...彼らは何もしません」と考えます。これは完全に論理的で通常の思考プロセスです (特に Rails 開発者として、私たちはコードを最小限に抑えて物事を効率化するのが大好きです!) が、ダークサイドに誘惑されてはいけません。
移行を削除すると、アプリケーションのデータ モデルの履歴記録が削除され、さらに悪いことに、現在のモデルに到達するために使用した論理パスが削除されます。この履歴は、自分がしたことをした理由としなかったことをしなかった理由を思い出すのに役立ちます。
はい、私たちは皆、時々移行を削除するという罪を犯してきました。ただし、純利益は数 kB とクリーンな移行フォルダーにすぎないため、誘惑に抵抗する必要があります。
覚えておいてください: 移行を削除する人は、それらを繰り返すことを非難されます!
個人的には、オプション 1 に傾倒しています。どのプロジェクトでも、ある時点でスキーマが重要であり、移行は単なる好奇心であることは一般的に真実ですが、移行によって何も害がないと言うのは正しいことです。理論的には、古い移行は、過去のある時点でデータベースがどのように構成されていたかを確認したい人にとって役立つ可能性があります。
それらを削除する際の深刻な落とし穴については知りませんが、新しい移行を編集するときにそれらをスクロールして時間を節約しない限り、そうする利点もありません。
スキーマを複製する単一の移行をまとめる作業は有益ではないと思います。それは余分な作業であり、とにかくそれがスキーマの目的です。
以前のプロジェクトの 1 つで、すべての移行を削除し、schema_migrations テーブルを手動の sql で切り捨てる新しいプロジェクトを作成し、db/schema.rb の内容をそこにコピーしました。確かに、この移行は元に戻せませんが、何百もの古い価値のない移行を取り除くことができましたが、db スキーマだけでなく移行からも db を再作成することができました。