Cursorをつかったページング - hidemonのブログ
1.3.1までは，データストアからの読み出し個数が1000個以下に限られていた．なので，1000個以上のデータを取り出すときに，rangeを使ってやろうとするとうまく動かなかった．というのは，range(990, 1010) とやると，0から1100までのキーをとりだして，その後，990から1010までの中身を取りに行く，という実装なので，0から1100までのキーを取りだすという時点で，落ちてしまうからだ．また，そもそも20個だけ読みたいのに，1100個キーを取りだしてしまうので非効率． これまでの方法 そこでよく知られているテクが，これ．条件式を組み合わせることで，rangeのオフセットを常に0にしたままスキャンする方法．このサンプルはPythonだけど，JDOで書いてもそのまま動く． 1.3.1 ところが，1.3.1になって事情が変わった．1000個の制約が無くなったので，とりあえず性
App Engine 1.3.1 - hidemonのブログ
でた．プレリリースが先週出ていて，その1週間後に予定通り本リリース．データストア周りが結構変わっていて，これまで苦労していた部分で苦労しなくて済みそうな感じ． Query Cursor いわゆるカーソルが導入された．RDBだと普通にあるのだけど，データストアからの読み出しにrangeで制約をつけておき，結果からカーソルを取得しておくと，次に同じキュエリをだすときに，カーソルを指定して，そのつづきから，という形で検索ができる． これまでだと，ソートのキーになっているプロパティの値を取っておいて，それを条件に加えて検索していたのだけど，そんなテクは不要に． No more 1000 result limit これまで，データストアには，1000個以上の値を返せない，という結構きつい縛りがあった．rangeで指定しても，たとえば 900-1100 みたいな検索ができなかった．この制約が無くなった
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
