#appengine 複数値プロパティの並び順は保証される
Yasuo Higa@ISID @yasuo_higa @urekat Protocol Bufferの仕様を見るのが確実ですが、listはそのまま保存されているはず #appengine > listプロパティって順番保証されてましたっけ？ 2010-02-26 10:48:59 Yasuo Higa@ISID @yasuo_higa #appengine のCollectionで順序が保証されないのはSetを使った場合、SortedSetなら大丈夫。じゃないとSortedSetがサポートされている意味がない。LLAPI的にはListで扱われます 2010-02-26 11:16:01
How Entities and Indexes are Stored - Google App Engine - Google Code
Python Overview CGI Environment Storing Data Overview Entities and Models Creating, Getting and Deleting Data Keys and Entity Groups Queries and Indexes Transactions Types and Property Classes GQL Reference Statistics Reference Model Expando PolyModel Property Query GqlQuery Key Functions Exceptions Services Memcache Overview Using Memcache Reference Client Functions URL Fetch Overview Reference T
#appengine でクエリの1000件超の結果件数を取得する方法
先のエントリで書いた#appengine でクエリの結果件数を取得する方法(1000件超とか)の続きです。 どーしても動的な条件に対する結果件数を…ていうなら、最悪Low-level APIでsetKeysOnly()しつつページング(常に条件を変えつつoffset0~limit1000で)、で数えるという手もあるかもしれない。これもまた試してみよう。この方法なら1000件につき約110msなんで、7000件でも770msくらいで数えきれるはずだ。 気になって眠れないので引き続きこちらの方法も試してみた。 手法 AppEngineでのページング手法としてBest practices for writing scalable applicationsでも書かれているページング方法で、setKeysOnly()を使う場合、使わない場合のふたつのパターンを試してみた。どちらもasList()を使
複雑なクエリのためのプロパティを仕込んでおく方法 - スティルハウスの書庫の書庫
以前、コンポジットインデックスを自作するというエントリを書きましたが、そのためにわざわざ新しいエンティティを作らずに、普通のエンティティにコンポジットインデックス代わりのプロパティを持たせる方法をちょこちょこ使い始めました。 例えば、以下のようなクエリを実行したいとき、 select * from Person where name == 'foo' & age >= 20 & age < 60 order by age asc このままではコンポジットインデックスを作らないとクエリ実行時にエラーが発生してしまいます。そこで、このエンティティPersonにプロパティsortKeyを追加します。このsortKeyには、name+ageの文字列を入れておきます。 bar:10 bar:29 foo:05 foo:25 foo:31 ... って感じです。数値を含める場合は「0」でパディングする
大きなコンポジットインデックスは自作した方が早いかも - スティルハウスの書庫の書庫
大きめのコンポジットインデックスを作ろうとしたら、管理コンソールのインデックス状態が「Error」となってしまいました。大きめといっても、2M件くらいなので“爆発”状態ではないのですが。。 MLで問い合わせしてみました。 http://groups.google.com/group/google-appengine-java/browse_thread/thread/18e26802d24f6d02# GoogleのJasonさんは「もう一回試せば今度はうまくいくよ！」と言うけど、そんなもんですか〜。 このコンポジットインデックスにはもうひとつ問題があって、テスト用に作った小規模の環境で動作を試したところ、複数プロパティに対するクエリがうまく動きません。うち1つのプロパティに不等式フィルタを追加すると、原因不明のエンティティの取りこぼしが発生してしまいます。取りこぼされるエンティティ自体は
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
App Engineのユニーク制限を正しく理解しよう - ひがやすを技術ブログ
Google App EngineではRDBMSのようなUnique Indexをサポートしていません。ユニーク制限を実現する場合は、トランザクション中でKeyを使ったgetとputを組み合わせる必要があります。 ここでは、email addressがユニークだったらそれを確定してtrueを返し、そうでない場合にはfalseを返すコードを考えます。 最初にトランザクションを使わないコードを見てみましょう。KeyFactory.createKeyの最初に引数は、kindといってテーブル名みたいなものです。 public boolean putUniqueEmailAddress(String value) { DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Key key = KeyFactory.cr
Song of Cloud: 送金のトランザクション処理パターン
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
#appengine JavaのLow-Level API(低レベルAPI)入門
追記このエントリについては今後はWikiでメンテナンスしていきますので、最新の情報はWikiで確認して下さい。 追記スティルハウス社の佐藤さんよりコメントを頂いたので一部の表現を修正しました。取り消し線+青字にしたりしてます。 追記ひがさんよりコメントを頂いたので、最後のTransactionについてのソースコードのサンプルを一部修正しています。子Entityをput()する呼び出しの第一引数にTranscationを指定するように修正しました。 ここから GAE/JのLow-level API（主にDatastore周り）については基本的にJavaDocしかなくて情報量が少ないと思ったので、それなりに使っていくための簡単な説明を書いてみる(@fumokmm氏の発言で思いつきました、Thx！)。 個人的な思いとしては、GAE/JのDatastoreについてJDOから入るのは間違いの元だJD
#appengine でクエリの結果件数を取得する方法(1000件超とか)
今日ひがさんと「クエリの結果件数の取得方法」についてTwitterで少しやりとりした。 Low-level APIのPreparedQueryだと1000件の上限があるが、JDOのQueryだと上限が無い 確かに上限は無いけど、JDOでQuery#execute().size()はめっちゃ遅くて現実的ではない JDOでもQuery#setResult("count(this)")は速い。でも、こいつは実はLow-level APIに丸投げなのでやっぱ1000件の上限に引っかかる。 JDOでもQuery#setResult("key")するとLow-level APIでいうsetKeysOnly()と同じ、キーのみクエリになる。でも1000件の上限に引っかからない！ 大体こんなカンジで、最後の件はひがさんが発見してGoogle App Engine for Java GroupのMLにPos
#appengine JavaのLow-Level API入門 Relationship編
前回のエントリが結構好評だったのと、前回のエントリだけだと、JDOから入った人は「Relationshipどーすんの？」となりそぅな気がしたので、調子に乗ってlow-level APIとJDOでのRelationshipの比較等について書きます。 JDOの方はLLParentクラスがOneToOneでLLChildAを、OneToManyでLLChildBを保持するような構成です。一方low-level APIではJDOと同じ事をキーのみでEntityGroupを構成します。LLParentkindは子エンティティのためのpropertyを一切保持しないと言う事です。JDOの方でもキーのみでEntityGroupを構成する事ができますが、ListPropertyで保持する方が一般的というかORMっぽいかなぁと思いまして。 一見、データの保持の仕方が全く違うよね？と見えますが、実はどちらの方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ranker.py - google-app-engine-ranklist - Project Hosting on Google Code
はてなブログ | 無料ブログを作成しよう
Sign in - Google Accounts