質問に文脈を少し与えるだけで、基本的にCRUD操作をMongoDbインスタンスにラップするWebアプリケーション（asp mvc）があり、モデルが検証される前に検証と特定のビジネスロジックを実行します保存され、検索されて保存されます。MongoDbでのマイグレーションの処理
新しいバージョンではモデルは変更されていますが、既存のデータは変更されていません。ここには例があります：実際には言語にとらわれない）
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string BadgeNo {get;set;}
}
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string EmployeeNo {get; set;} // Still contains same data as BadgeNo just called something different
}
オブジェクトの構造は変更されていますが、Mongo land i tはまだ従業員ではなく、BadgeNoを渡しています。 SQLの土地では、通常、スキーマを変更し、そのデルタの追加データを更新/挿入/削除するビルドスクリプトの一部として実行される移行スクリプトがあります。
このような種類のマイグレーションをMongoで管理するにはどうすればよいですか？ Mongo内のすべてのインスタンスを更新するために使用するスクリプトも用意する必要がありますか？この種のことをするための他の好ましい習慣があります。
件名に何かアドバイスは素晴らしいことだ
===編集===は
それは、現在、私はこれをので、フェージングアウトのアプローチではなく、移行オプションと一緒に行くを希望していますように思えます誰もがこの分野で助けてくれるツールをお勧めします。そうでなければ、各マイグレーション（ロールイン、ロールアウトを前提とする）は、すべてのロジックを含むある種のコンパイル済みアセンブリでなければなりません。 FluentMigratorの行はSQLで作業するのではなく、Mongoと作業しています。現在私のビルドスクリプトはNantを使用していますが、いくつかのルビーツールを見ていますが、.netに相当するものがあるかどうかはわかりません。
私はオプション1を選択し、そのコードを使用して、後でオプション2を実行するマイグレーションユーティリティ（たとえば、コマンドラインアプリケーション）を作成します。古いバージョン。 –
良いアイデアショーン、私は私の答えを更新しました。 – Derick
問題は、複数のバージョンだけをサポートするために維持する必要がある余分なコードがたくさんあり、変更されたモデルごとに20個のファイルが20行あると想像してください。私にとっては、2つ目のオプションは、バージョン間の移動（ロールバックなど）が容易であるほど良いと思われますが、私は少量のダウンタイムには問題ありません。私がオプション2を言うことを多くの人が期待していたので、答えをお寄せいただきありがとうございますが、2番目のアプローチ、つまりビルドスクリプトをどのように自動化するのが最適かを考えていました。 – Grofit