Ravendbの「スキーマ」を変更します

StackOverflow https://stackoverflow.com/questions/4776873

  •  23-10-2019
  •  | 
  •  

質問

知識を拡大するためだけに、さまざまなNOSQLオプションを検討し始めました。私が最初に訪れたのはRavendbで、面白そうです。私はまだ、典型的なRDBMSメンテナンスルーチンとともに、深く座っている関係思考を破ろうとしています。

エンティティフレームワークを扱う私の日々の扱いにおいて、DBの変更、EFマッピングモデルのリフレッシュなどのルーチンを通過します。特にRavendBでどのように機能しますか？アプリが命を吹き込んだら、どのようにしてさまざまなPocoオブジェクトなどを変更し、それを生産に展開しますか？古いPocoクラスに保存されているデータはどうなりますか？

私はまだ深く掘り下げたり、レイヴンDBを怒りにしていません。これは私がやると明白かもしれませんが、手の前に知りたいので、自分自身をコーナーにコーディングしません。

ありがとう。

役に立ちましたか？

解決

彼らはそのままです - 存在しなくなっていないプロパティは、ロードするときに無視されます（そして変更で失われます）。

セットベースの操作を使用して、オブジェクトモデルでデータを抑えることをお勧めします。

ああ、私を見てください、私は今コンピューターに乗っています！

基本的には、ドキュメントストアに移動する際に、データベースで機能を失い、その中で自由度を得ることが正しいことを認識しています。エラーが発生します。

ただし、ドキュメントにはすべて独自の構造（プロパティ名とプロパティ値を示すキー/値ペア）が含まれているという点で、スキーマレスと構造のない間に違いがあることを認識することが重要です。

これにより、コードを作成してデータを持続させる要因全体に役立ちますが、コード構造の変更を非常に簡単に変更できる場合は、既に持続したデータでそれを調整するのが難しい場合があります。

この時点でいくつかの戦略が現れます：

  • あなたが持続したら、あなたの構造を不変にします、あなたのクラスのバージョン、バージョン
  • 構造の変更を許可しますが、セットベースの操作を使用してデータを更新して新しい構造に一致します
  • 構造の変更を許可し、データをロードするときに矛盾に対処するためのコードを書き込む

3番目は明らかに悪い考えです。それは維持不可能なコードにつながるため、イベントやその他のデータを保存しているだけでなく、ほとんどのシナリオには実際には適切ではない場合にクラスのバージョンを機能させることができます。オプション。

それを行うことをお勧めします。また、リレーショナルデータベースの前向きなスキーマを扱う際に従うのと同じ行に沿っていくつかの簡単なルールに従うことをお勧めします。

  • VCSシステムを使用して、展開バージョン間の変更を決定します
  • あるバージョンから別のバージョンにアップグレードする移行スクリプトを作成する
  • 名前の変更/プロパティの削除に注意してください - ドキュメントをロードしてドキュメントを保存すると、新しいドキュメントにそれらのプロパティが存在しない場合、データが失われます。

等。

これがもっと役立つことを願っています:-)

他のヒント

RavendBは、.NETオブジェクトをJSON形式にシリアル化します。スキーマはありません。

データベースにオブジェクトを追加すると、シリアル化されます。シリアル化しているタイプにプロパティを追加すると、既に保存しているオブジェクトにはそれらのプロパティがありません。

Ayendeのこの記事では、1からバージョン2への移行を実行する方法について説明します（この場合、「名前」プロパティを「FirstName」および「LastName」プロパティに変更します。

http://ayende.com/blog/66563/ravendbmigrations-rolling-updates

基本的に、リスナーがDocumentStoreに登録されています。

documentStore.RegisterListener(new CustomerVersion1ToVersion2Converter())

上記の記事から撮影したサンプルの印刷：

public class CustomerVersion1ToVersion2Converter : IDocumentConversionListener
{
    public void EntityToDocument(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;

        metadata["Customer-Schema-Version"] = 2;
        // preserve the old Name property, for now.
        document["Name"] = c.FirstName + " " + c.LastName;
        document["Email"] = c.CustomerEmail;
    }

    public void DocumentToEntity(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;
        if (metadata.Value<int>("Customer-Schema-Version") >= 2)
            return;

        c.FirstName = document.Value<string>("Name").Split().First();
        c.LastName = document.Value<string>("Name").Split().Last();
        c.CustomerEmail = document.Value<string>("Email");
    }
}

スキーマ管理はあまりありません。コードに移動すると、コードのオブジェクトとデータベースのオブジェクトの間に不一致はありません。

変更の処理の最初の部分は、欠落/追加の値を処理できるシリアナーを使用することを確認することです。データでフィールドが定義されていない場合は、nullに設定します。データ内のフィールドがオブジェクトのプロパティと一致しない場合は、無視してください。

ほとんどの変更はそれ以上に処理することができます - 新しいフィールドがあり、とにかく既存のレコードにデフォルト値が必要であるか、それ以上気にしない古いフィールドがあるかのいずれかです。

フィールドの変更/組み合わせやデータ形式の変更などのより複雑な変更については、古いフィールドを削除せずにオブジェクトに新しいフィールドを追加し、古いフィールドからロードメソッドを転送します。レコードを保存すると、新しい形式になります。このコードは、必要に応じてデータを更新して永続的に配置したままにしておくことができます。または、既存のすべてのオブジェクトの同じコードを呼び出すために1回のプロセスを設定することができます。 SQLスクリプトとは異なり、コードは古い形式と新しい形式の両方を処理できるため、大規模なデータセットで実行するのに長い時間がかかったとしても、このタイプのアップデートにはダウンタイムが必要ではないことに注意してください。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top