問題タブ [app-engine-ndb]

複数の人が持っている金額を保存したい GroupWallet モデルがあります。この情報は、個人、個人キー、および金額で構成されます。つまり、タプルのリストを保存したいと言うことができます

(GroupWallet と Person の間の) リレーショナル オブジェクトを試してみましたが、うまくスケーリングできませんでした。

、などの 3 つの並列リストを作成し、インデックスを使用してタプルをリンクすることを考えていNamesます。しかし、私はその解決策が好きではなく、NDBと StructuredProperty に出くわしました。しかし、NDB には存在せず、元の db ライブラリにのみ存在する PolyModel も必要です。NameKeysAmount

私の質問は次のとおりです。独立した StructuredProperty の実装を知っている人、または PolyModel が NDB にすぐに実装されるかどうかを知っている人はいますか?

アップデート

これは、次のスキームを作成するための私の最善の努力でした

元の質問

どのユーザーがどのユーザーの「スポンサー」であるかを示すために、expando クラスで自己参照を作成するにはどうすればよいですか? 「スポンサー」は新しいユーザーを招待した人であるため、作成時にそれを保存する必要があり、文字列または文字列リストよりも参照プロパティとして保存する方がはるかにきれいです。

新しいユーザーを作成できますが、参照を作成する方法がわからないため、あるユーザーの別のユーザーが最初のユーザーのスポンサーであることがわかります。これをモデル化する方法は、両方のオブジェクトはユーザーですが、複雑なのはそれがexpandoモデルであるため、参照プロパティの使用方法がわかりません。その方法を教えていただけますか、またはこの問題を最善の方法で解決する方法の手がかりを教えていただけますか?

epando モデルで実際の参照プロパティを保存する最後の部分を行う方法がわかりません。どうすればそれができますか？

アップデート

できないようです：

NotImplementedError: Property sponsor does not support <class 'google.appengine.ext.db.ReferenceProperty'> types.

コード：

参照の代わりに文字列を使用することを余儀なくされ、解決策が実行可能になります。

ドキュメントは、それらが同様に使用できることを示唆しているようです。違いは何ですか?また、それぞれをいつ使用する必要がありますか? 最適なパフォーマンスを得るには、どちらを使用する必要がありますか (どちらも「最速」であることを示唆しているため)。

context.map_query のドキュメント: https://docs.google.com/document/d/1rPyB2RmRERAZDPpqy2cxzXeDGyfLhX-s-3dFVpnwFXw/edit?hl=en_US#heading=h.wniiq5a4ja4o

qry_obj.map_async のドキュメント: https://docs.google.com/document/d/1rPyB2RmRERAZDPpqy2cxzXeDGyfLhX-s-3dFVpnwFXw/edit?hl=en_US#heading=h.t1t6424hbp7y

NDBを使用するようにアプリを変換しています。私は以前このようなものを持っていました：

ご覧のとおり、リストを生成する私の方法は少し複雑なので、この方法で保持することを好みます。しかし、NDBに変換し始めたとき、置き換え@db.ComputedPropertyただけですが、次の@model.ComputedPropertyエラーが発生しました。

model.pyext.ndbで、タイプに応じて値を処理するif / elseステートメントがいくつかあるところComputedPropertyから継承していることがわかりました。ただし、GenericProperty_db_set_valuelists

現在、最初の条件を通過し、空のリストを返すとそのエラーが発生します。

これを回避してエラーを回避する方法はありますか？

マニュアルには、db.allocate_id_range の使用例がありません。私はいくつかのコードを試してみましたが、特に ndb expando モデルである webapp2:s User モデルで失敗しました。私がやりたいことは、選択した ID 番号を持つ User エンティティを作成するだけなので、db.allocate_id_range を使用しようとしましたが、機能していません。

私がやろうとしている方法はこのようなものです

first_batch = db.allocate_id_range(User, 3001, 3001) #try allocate ID 3001

私はそれを間違っていますか？モデル名を引用符で囲んでみましたが、それもうまくいきませんでした。これをどのように行う必要がありますか？アドバイスをありがとう。

Keys over String を Google App Engine データストアに保存する利点はありますか。

例えば：

VS

• StringID の代わりに Key を格納する必要があるのはなぜですか? 便宜上だけですか？
• 使用するストレージ スペースが少ないのはどれですか?
• クエリが速いのはどれですか?

mapreduce.input_readers.DatastoreEntityInputReader は、種類の低レベル データストア エンティティを生成します。その低レベルのデータストア エンティティを ndb.model.Model ベースのエンティティに変換できますか?

Google App Engine の 1.6.2 SDK の NDB で Python 2.7 ランタイムを使用しています。

次のエラーが表示されます。

BadRequestError: アプリ s~myapphr はアプリ dev~myapphr のデータにアクセスできません

このコードから:

myapphr にエイリアスされている dev.myapp.appspot.com からアプリにアクセスしています。device_id は、同じ dev.myapphr バージョンで作成されました。

何が起こっている？

データストアのシンプルさ、スケーラビリティ、使いやすさが気に入っています。そして、新しいndbライブラリに見られる拡張機能は素晴らしいものです。

データストアのベスト プラクティスを理解しているので、クエリに一致するアイテムの数が多い場合、一致するクエリ結果のアイテム数やページ数を提供するコードを記述しないでください。これを行う唯一の方法は、リソースを集中的に使用するすべての結果を取得することです。

ただし、私たちのアプリケーションを含む多くのアプリケーションでは、一致するアイテムの数を確認し、ユーザーがそれらの結果の特定のページに移動できるようにすることが一般的に望まれます。データストアのページングの問題は、大きなデータセットを介したページングの記事で概説されているように、fetch(limit, offset=X)の制限を回避する必要があるため、さらに複雑になります。. 推奨されるアプローチをサポートするには、結果が表示される方法で順序付けできる一意の値を持つ列がデータに含まれている必要があります。この列は、結果の各ページの開始値を定義します。それを保存すると、対応するページを効率的に取得でき、要求に応じて特定のページまたは次のページに移動できます。したがって、複数の方法で並べ替えられた結果を表示する場合は、そのような列をいくつか維持する必要がある場合があります。

SDK v1.3.1 の時点で、クエリ カーソルはデータストアのページングを行うための推奨される方法であることに注意してください。IN および != フィルター演算子がサポートされていないなど、いくつかの制限があります。現在、重要なクエリのいくつかはINを使用していますが、クエリ カーソルで使用するためにORを使用して記述してみます。

提案されたガイドラインに従って、ユーザーには(次へ)および(前へ)ナビゲーション ボタンと、ナビゲーションが進むにつれて特定のページ ボタンが与えられます。たとえば、ユーザーが(次へ)を 3 回押した場合、アプリは次のボタンを表示し、それぞれの一意の開始レコードまたはカーソルを記憶して、効率的なナビゲーションを維持できます。(前) (ページ-1) (ページ-2) (ページ) -3) (Page-4) (次へ) .

カウントを個別に追跡することを提案する人もいますが、返される結果が異なる豊富なフィールド セットに対してユーザーがクエリを実行できる場合、この方法は実用的ではありません。

これらの問題全般と、具体的には次の質問に関する洞察を探しています。

1. これらの制限を回避するために、データストア アプリでクエリ結果のどのようなナビゲーション オプションを提供していますか?

2. ユーザーに効率的な結果カウントとクエリ結果セット全体のページ ナビゲーションを提供することが優先事項である場合は、現在提供されているGAE MySql ソリューションを優先して、データストアの使用を放棄する必要があります。

3. ビッグ テーブル アーキテクチャまたはデータストアの実装に、クエリの結果を効率的にカウントするための追加機能を提供する今後の変更はありますか?

ご協力いただきありがとうございます。

私は非同期APIに頭を悩ませようとしていますが、あまり成功していません。

私のラボプロジェクトでは、かなり単純なセットアップです。次のようなモデルがあります。

また、get_or_insert を使用するメソッドと、reference_list にキーが含まれているかどうかをチェックし、含まれていない場合は追加します。エンティティの下にはモデル エンティティがあり、リストは文字列のリスト ["abc","def","ghi"] です。

これは私が望んでいたように機能しましたが、時間がかかりました。リストの長さが約 20 ～ 30 倍だった場合。約15〜20秒かかりました。

そこで、非同期APIを調べ始めました。しかし、あまり遠くに行かないでください。現在、データベースには何も保存されていません:

主にタスクレットとyieldの概念を理解していないため、どこにあるのかよくわかりません。誰でも何か考えがありますか、それとも私を方向に向けることができますか?

編集：

私はこの解決策になりました：

そして @ndb.toplevel を get-request ハンドラーに追加します。そして、それはずっと速いです！

また、この質問をhttps://groups.google.com/forum/?fromgroups#!topic/appengine-ndb-discuss/L4DEsYdEwTEに投稿し、いくつかのフォローアップの質問を含めました