問題タブ [app-engine-ndb]

アプリケーションを db から ndb に変換する作業を行っており、クエリをより効率的にする作業を行っています。データ量の増加に伴い、アプリケーションが少し遅くなり、クエリがかなり非効率的であることがわかりました。

バックグラウンド：

簡略化したデータ モデルは次のようになります (批判は自由です)。

管理者は ServiceRequest の ServiceRequestApplication を「承認」できます。ServiceRequestApplications は、親 ServiceRequest でインスタンス化されます。ServiceRequestApplication が承認されると、アプリケーションのキーが要求のアプリケーション プロパティに格納されます。

トリッキーな部分：

1 つの実際のサービス予定 (技術者ごとに 1 つ) に対して複数の ServiceRequest エンティティが存在する場合があります。1 つの ServiceRequest があり、複数の技術者が必要な場合は、メインの ServiceRequest を親として追加の ServiceRequest を作成します。このデータがクエリ/表現される方法に関するいくつかの他の理由を含め、祖先クエリは非常に簡単であるため、最初はこの方法で問題に取り組みました。

子 ServiceRequests を持たないServiceRequest エンティティを照会する方法を考えられる人はいますか?

ありがとう！

Google App Engine (Python) で ndb.Models/Expandos のコンテンツのバージョン (履歴) を追跡するためのシステムを作成しようとしています。

コンテンツは比較的長くなる可能性があり、多くのバージョンが存在する可能性がありますが、バージョン間の違いは非常に小さい場合があります. 他の人がこのようなことをしたと思います。彼らがどのようにそれを行ったのか、どのような原則が設計と開発の指針となるかを知りたいです。

データ モデルの属性が何であるか (たとえば、「タイトル」、「コンテンツ」、「本文」、「日付」など) はデプロイ時にはわかりませんが、タイプはわかっています (日付、テキスト、等）。

私の最初の考えは、次のようなものを配置することです。

アルゴリズムの概要は次のとおりです。

保存

ユーザーがドキュメントを保存するたびに、最新のデータをすべて新しいものに入れ、そのインスタンスVersionをポイントします。head

その時点で、またはしばらくしてから、古いバージョンを調べて、完全な保存を diff に変更します (スペースを節約するため) などを使用しますdiff-match-patch。1時間、1日、または設定された時間ごとに1回の完全な保存、または設定された数の差分が期待されます。

読み込み中

読み込みheadは簡単です。

古いバージョンは、完全な保存または差分としてマークされ、データが直接返されるか、差分からコンパイルされるかに応じてマークされます。

考え？

他の人がこの問題に取り組んでいると確信しており、それについてどのようなアイデアや実装があるか知りたい. 明らかに、Git、Mercurial、Subversion、CVS などの完全なバージョン管理システムがありますが、これらはどちらも意図した目的には過剰であり、Google App Engine では機能しません。

アプリをデータストアから ndb に変換していますが、xml インポート ルーチンで問題が発生しました。問題は、ndb.model クラスのプロパティが多値プロパティかどうかをプログラムで判断できないことです。

私がこれまでに思いついたコードは値が「目に見える」ことを示しているので、これは基本的な Python スキルの欠如が原因であると思われます。したがって、私はそれをつかむことができません。助けてください。

これにより、次の結果が得られます。

私は、GAEとPython2.7ランタイムの上に最初のRESTfulWebサービスを作成しているところです。Guidoの光沢のある新しいndbAPIを使い始めました。

ただし、元のdbAPIの暗黙的な後方参照機能を使用せずに特定のケースを解決する方法がわかりません。ユーザーエージェントが特定のリソースを要求し、それらのリソースが1度削除された場合：

host / api / kind / id？depth = 2

関連するエンティティの種類が開発時に不明であるとすると、1対多の関係にある「1つ」から関連するエンティティのコレクションを見つけるための最良の方法は何ですか？

• 後者の制限のため、前のSO照会で説明したように置換照会を使用できません。モデルが実行時に定義可能である（したがってハードコーディングされていない）という事実により、クエリを使用して一致するキーのプロパティをフィルタリングすることができません。

• データストアの制限により、種類を指定せずにプロパティをフィルタリングできないため、祖先やその他の種類のないクエリも使用できなくなります。

これまでのところ、（db apiに戻る以外に）私が持っていた唯一のアイデアは、グループ間トランザクションを使用して、次のようなndb.StringProperty（repeat = True）を更新することにより、「1つ」に独自の参照を書き込むことです。新しい種類のエンティティが導入されたとき、または関連する「多くの」エンティティがデータストアに書き込まれるたびに「1つの」ndb.KeyProperty（repeat = True）にキーのリストを保持することによって、関連するすべての種類。

私よりも経験豊富な人がより良いアプローチを提案できることを願っています。

jmort253の提案を踏まえて、ドキュメントから採用した具体的な例を使用して、質問を補強してみます。

次のようなキーを使用して、アイテムのバッチを取得しています。

appstats での結果は次のとおりです。

逆ウォーターフォールの問題は、それぞれ独自の RPC でキーが 1 つずつ並行して送信されることが原因のようです。

私の質問は、単一の RPC 呼び出しで複数のオブジェクトをキーで取得する方法はありますか? (これにより、アプリの全体的な応答時間が短縮されると仮定します)。

実験段階ではなくなったので、ndbの使用に移行します。再考する必要があることがいくつかありますが、問題があるのは、モデルエンティティのクライアント側の一意の識別子を取得することです。次のようにエンティティを取得してクライアント側に送信します

次に、クライアント側で各エントリを繰り返し処理し、モデルエントリをさらに調査するためのリンクを設定します。

以前はasdfer234234===のような一意の識別子を取得していましたが、現在は{{question.key}}からKey（'Questions'、％203）のようなものを取得しています。次に、この一意の識別子をキャプチャして、次のように使用します

この動作をndbで複製するにはどうすればよいですか？

Google AppEngine の Ndb で GQL クエリから取得できる結果の最大制限は何かという回答を得るために、私は周りを見回しています。カーソルを使用した実装を使用していますが、一度にすべて取得するとはるかに高速になります。

私は Appengine 1.6.5 を使用しており、Jinja2 テンプレートから NDB モデル クラス プロパティにアクセスしています。代わりに、ループで同じプロパティにアクセスすると正しい結果が得られました。問題を説明するために、いくつかのコードを投稿します

--- モデル ---

--- ハンドラ --- これはハンドラの一部です

--- テンプレート --- これはテンプレートの一部です

従業員の車の登録番号を取得する正しい方法を誰か教えてもらえますか? 前もって感謝します

よろしく、 ロベルト

NDB からエンティティを読み取るために get_by_id() を使用していますが、エンティティ グループの一部であるエンティティに対しては機能しません。

出力：

設計によるものですか、それともバグですか？以前に名前空間を使用したときに get_by_id() に関連する問題がいくつかあったことがわかりました (私は SDK 1.6.6 を使用しています)。ID からの親を持つフォルダーはどうすればよいですか?

間違っているかもしれませんが、私は常にアプリに次のクエリを使用しています。

この NDB のクエリの互換バージョンは何ですか? メタデータ クエリは大きく異なります。

edit : cid はエンティティであり、cme_only は iterable であり、値が 1 つしかないと確信しています

そしてテンプレートで：

私はそれが好きではありませんでしたが、それで十分でした