0

次のように構造化された親子関係を持つデータモデルがあります。

Container
  Metric
    Value

これらの各モデルには「ステータス」フィールドがありますが、値モデルのみがそのフィールドに入力できます。他のモデルには、祖先の値モデルの「ステータス」フィールドに基づいて変化する ComputedProperty があります。現状では、モデルが直接読み取られると (@property の動作と同様に) 親で現在の結果が得られますが、モデルがクエリの一部である場合は古い結果が得られます。

したがって、子モデルのステータスが更新されたときに、親モデルの「ステータス」フィールドを更新する必要があります。_post_put_hook()更新されるたびに、値モデルとすべての親だけを入れることができることはわかってput()いますが、それは高価に思えます。

  • 両親に子供たちを「見て」もらう方法はありますか？
  • 「ステータス」プロパティで親をクエリするための安価な回避策はありますか? (そのため、ComputedProperty を使用する必要はありません)
  • 使用しているモデルが多すぎますか? 1 つの put() がすべてを配置するように、StructuredProperties としてそれらをマッシュアップする必要がありますか? （ただし、子供の前に親のステータスを更新することにも問題がありました）
  • 私が見逃しているものは他にありますか？
4

1 に答える 1

0

インデックスの場合、結果整合性が得られます。つまり、通常は 1 秒程度で更新されますが、保証はありません。

現在の設計では (一貫性の要件によって異なります)、おそらく _pre_put_hook を使用して、ステータスの更新をトランザクションで行う必要がある場合があります (これにより、トランザクションを開始できるようになります)。3 回の書き込みですが、エンティティ グループ内の 3 つのネストされたエンティティを更新する必要がある場合、それを回避する方法はありません。

「ウォッチ」または自動イベント/トリガー処理が利用できるとは思いません。

これが常に 1 対 1 の関係である場合は、これを常にステータスを持つ単一のオブジェクトにすることが理にかなっています。潜在的な欠点は、更新するたびにすべてを書き戻さなければならないことです。これは、大きなオブジェクトのオーバーヘッドが大きくなります。利点は、任意のプロパティに対してクエリを実行できることです。

すべてのレベルでステータスやその他のプロパティをクエリする必要がある場合は、どこでもステータスが必要です。それ以外の場合は、クエリに使用できる必要があるエンティティにステータスを移動できます。

コンテナやメトリクスの他のプロパティではなくステータスのみをクエリする場合は、次のようなことができます

[value_key.parent().parent().get() for value_key in Value.query().get(keys_only=True)]

値クエリからコンテナのリストを取得します。

于 2012-10-18T12:06:57.340 に答える