多くの人がデータベースの移行、特にロールバックの可能性について話しています。
db と model のスキーマはアプリケーション ロジック (MVC) と密接に接続されているため、まったく役立つかどうかは疑問です。
いくつかの移行のロールバックを行ったとします。そして何 ？アプリケーションのロジックは db に完全に依存しているため、アプリケーションは機能しません。
データベース移行のロールバック機能の使用例は何ですか?
更新 1
主な質問
コードを変更する必要があるのに、ロールバックが機能として表示されるのはなぜですか?
「add_another_field_to_table」のような移行は作成しません。代わりに、各移行ファイルは DB 内の各テーブルを完全に記述します。DB で何かを変更する必要がある場合は、移行ファイルを変更するだけで、ロールバックはしません。
実際、移行をロールバックしても、バージョン管理のように元に戻すことはできません。変更が計画され、ロールバックが何も得られないとき、私は多くの仕事をしています。
ロールバックのポイントは、コードとDBを同時にロールバックすることです。シナリオは、本番サーバー上のコードとDBをアップグレードした後、バグを見つけて、本当に戻る必要があるというものです。したがって、コードをロールバックし、ダウンマイグレーションを使用してDBをロールバックします。
ロールバックが役立つのは、ローカルで実行する場合、つまり、新しいコードを作成している場合のみです。移行がバージョン管理システムにコミットされると、間違いがあったことに気付いた場合、他の開発者が移行をプルして実行するため、移行をロールバックすることは実際には機能しません。同様にロールバックするように伝えてください - これは管理が難しすぎて、あなたが無能に見えることにもなります :)
この状況では、問題を解決するために別の移行を行うほうがよいでしょう。そうすれば、全員 (本番サーバーを含む) はプル & 移行システムに固執するだけです。
Up マイグレーションのポイントは何ですか?
これをどのように処理しますか？開発テーブルに列を追加し、コードをテストし、同時にライブ DB を更新することを忘れずにライブ サイトを更新する必要があります (そうすると大きなエラーが発生します)。また、既存のライブ データを保持することも忘れないでください。DB 管理のこの側面は、Rails のような優れたマネージド ソリューションがなければ、本当に苦痛になる可能性があります。
そう ...
これで本番環境でリリースする準備ができました ....
確かに、1 つの列を追加することで、自分で行うのはそれほど混乱しません。
しかし、3 人のプログラマー全員が移行を追加しているとしたらどうでしょうか? 多数のライブ サイトがあり、すべてが異なるバージョンである場合はどうなりますか? そのライブ サイトは 2 つまたは 17 移行遅れていますか? ライブ データを保持しながら、DB を最新のコードにするにはどうすればよいですか? これを処理するのが非常にすぐに混乱することがわかりますか?
Rails の移行 (そして実質的にすべての移行システムは同じ原則に基づいて動作します) は、DB 構造の更新を非常に簡単にするように設計されています。適切に使用する価値があります。
あなたの問題を本当に理解していませんが、ロールバックについて少し説明しようとしています。それぞれの移行による変更を元に戻したい場合は、ロールバックを行います。これは、データベースが変更され、schema.rb が自動的に再生成されることを意味します。これを行う場合、おそらく参照コードも削除する必要があります。たとえば、モデルからフィールドを削除した場合、おそらくコードでその属性を参照したくないでしょう。アクセスしようとすると、未定義の属性例外が発生します。それでおしまい。たとえば、以前にモデル 10 の移行をいくつか作成していて、いくつかのフィールドを変更したい場合など、ロールバックが少し面倒になる可能性があります。それぞれの移行にロールバックするのではなく、新しい移行を作成してそこで変更することをお勧めします。
更新 1
あなたの更新を読んでください。移行の主な利点である柔軟性を使用していないと思います。しかし、あなたのソリューションは、データベースの状況のより多くの概要を提供します。そのようにしたい場合は、次の手順を順番に実行することをお勧めします。
rake db:migrate VERSION=XXX。rake db:rollback STEP = 2STEPrake db:migrate)この機能はモデルなどには影響しません。移行ファイルを変更し、schema.rb を再生成し、データベース構造を変更するだけです。バージョン管理システムのようにコードをロールバックすることはできず、そのようなことをする意味がありません。削除されたフィールドを使用しないように注意する必要があります。Rails では、データベース フィールドとモデル属性の間のマッピングが自動化されています。たとえば、テーブルに がある場合user_id、commentそれをモデルの属性として呼び出すことができますcomment_instance.user_id。
カピストラーノを使用してサイトをデプロイし、各デプロイのタイムスタンプ付きスナップショットを作成するシナリオを考えてみましょう。フォルダーと移行のタイムスタンプを使用して、コードとスキーマのどのバージョンが関連しているかを特定し、ロールバックを実行できます。
git リポジトリでも同様のオプションが提供されます。
もちろん、実際の問題は、サイトのユーザーがデータを追加し始めると、ロールバックの前にデータをバックアップし、後で念入りに復元しない限り、データが削除される可能性があることです。
rake db:migrate:redo移行コードの作業中および最終コミットの前に、移行ロールバックをローカルで使用します。