この回答で説明されているような、DB スキーマの変更を追跡するためのメカニズムをセットアップしたいと考えています。
データベースに変更を加えるたびに、新しい移行を作成します。通常、移行には 2 つの方法があります。変更が適用される「上」の方法と、変更が元に戻される「下」の方法です。1 つのコマンドでデータベースが最新の状態になり、データベースを特定のバージョンのスキーマにするために使用することもできます。
私の質問は次のとおりです。「up」メソッドのすべての DDL コマンドは元に戻せますか? つまり、常に「ダウン」メソッドを提供できますか? 「ダウン」できない DDL コマンドを想像できますか?
「up」メソッド中にデータが失われる典型的なデータ移行の問題を考慮しないでください。たとえば、フィールド タイプをdatetime( DateOfBirth)からint( ) に変更すると、YearOfBirth復元できないデータが失われます。
SQLサーバーでは、私が知っているすべてのDDLコマンドはアップ/ダウンのペアです.
データの損失を除けば、これまでに行ったすべての移行は元に戻すことができます。とはいえ、Rails は移行を「破壊的」とマークする方法を提供しています。
一部の変換は、元に戻すことができない方法で破壊的です。その種の移行では、down メソッドで ActiveRecord::IrreversibleMigration 例外を発生させる必要があります。
こちらの API ドキュメントを参照してください。
はい、データを変換するか、単に "up" 移行で COLUMN を削除することにより、データを失うケースを特定しました。
もう 1 つの例は、SEQUENCE オブジェクトをドロップして、その状態を失う可能性があることです。「ダウン」移行はシーケンスを再作成しますが、1 からやり直します。これにより、シーケンスによって重複する値が生成される可能性があります。空のデータベースで移行を実行していて、シーケンスを 1 から開始したい場合は問題ありませんが、データ行がいくつかある場合は、シーケンスを最大値にリセットする必要があります。そのテーブルに排他ロックがない限り、これを確実に行うのは困難です。
データベース内のデータの状態に依存するその他の DDL には、同様の問題があります。そもそもそれはおそらく良いスキーマ設計ではありません。私はあなたの質問に合ったケースを考えようとしています.