GQLで好きなもの; StringListPropertyまたはListProperty？

Question

私は多対多の関係を持つアプリケーションを構築しています。 エンティティ 'ピクチャ'のアイテムは、任意の数のギャラリー（ 'ギャラリー'）にリンクできます。もちろん、ギャラリーにはいくつでも写真を保存できます。

ここでGoogleの提案にしたがって、「ギャラリー」の外部キーを保持する「ピクチャ」のリストを使用します。これはBigTableのアプローチです。

（古いスタイルリレーショナルDBのアプローチは、「絵」と「ギャラリー」の間にテーブル/エンティティを持っているだろう。）

ここ

は私の質問です：キーを保存するとき、私はのために行く必要があります」 StringListProperty "を 'Picture'にするか、" ListProperty（db.Key） "がうまくいくでしょうか？

私がのStringListを見る理由の1つは、キーと他の値を保存することができますが、それ以外の場合は、とにかく汚れたスタイルになります。しかし、インデックスが爆発するため、Googleがエンティティで複数のListを使用しないように提案していることも確信しています。これは私をバックドアにしてくれるでしょう。値が実際にキーである場合、自動検証であろう「キー」ワンポイントタイプListPropertyとして

。

文字列をキーに変換したり、その逆に変換するのは非常に簡単なので、リストの種類のいずれかがここで優先される理由はありません。

パフォーマンス上の問題については、どのようにテストすることはできませんが、これがこの決定の主な要因になるようです。

あなたの意見が不思議です。特に、誰かがこれについてのパフォーマンスをテストしているか、それほど親切でそれをやっているでしょう。あなたは、キーのリストを格納することを意図している場合

乾杯、 //ハンネス

Answer 1

はdb.ListProperty(db.Key)を使用してください。それらは、文字列リストで使用する文字列表現よりもコンパクトなバイナリ表現で格納されます。

リスト内の他のオブジェクトとキーをミキシングするのは面倒です。 1つのエンティティに複数のリストがあるのは、同じカスタムインデックスで2つ以上のインデックスをインデックスに登録しない限り、インデックスを爆発させる原因となります。

Answer 2

db.ListProperty（db.Key）を使用してください。これは、データベースモデルにプロパティがある場合、データフェッチをstringよりも簡単にします。リストを含むdb.ListProperty（db.Key）タイプのpic_listを持っていればピクチャがあなたのエンティティの名前であると仮定しましょう。次にPicture.get（// GalleryObject //。pic_list）はすべてのピクチャのエンティティを取得します..