0

私が取り組んでいるアプリケーションは、REST通信を使用するクライアント/サーバーです。サーバー側でdb4oを使いたい。クライアントはエントリを更新または作成できます。したがって、オブジェクトは「ObjectContainerの外」から更新するためにクライアントからサーバーに戻ります。

させて：

  public class IdHolder
  {
    public Guid Id {get; set;}
  }

  public class MyClass : IdHolder
  {
    public string SomeData {get; set;}
    public IdHolder Child {get; set;}
  }

ご覧のとおり、クラスMyClassにはIdHolderへの参照があります。

db4oのドキュメントによると、私には2つの解決策があります。1。内部Uuid2.手動GUID処理

ケース1の場合、クライアントは、適切ではない特定のタイプdb4o.Uuidを認識するために、db4oアセンブリへの参照を持っている必要があります。

ケース2（上記のクラス定義で暗黙的に）の場合、Guid処理は便利ですが、db4oは内部IdHolder参照を認識しません。例えば：

  • o1はDBに保存されたIdHolderです
  • o2は、o2.Child==o1のMyClassです。

o2が保存のためにサーバーに送信されると、db4oはo1がすでに存在することを認識せず、そのo1.Idで見つけることができるため、o1の重複エントリがDBに保存されます。

問題は、db4oを使用して切断されたシナリオを処理するための最良の方法は何ですか？

編集：

ドキュメントがそのような問題を扱っている場合、この部分。「マージ」。私にはあまり満足していないようです。私はあなたの概念的/技術的アイデアにオープンなままです。

4

1 に答える 1

1

基本的に、db4o側ではそれをサポートしていません。ドキュメントが言うように「マージ」は基本的にあなたが持っている最良のオプションです。

このため、db4oはWebアプリにはあまり最適ではありません。（また、本質的にシングルスレッドであるため、スケーリングも行われません。）

于 2012-11-12T16:07:11.893 に答える