2008-04-16
Datastore に泣いたアナタに捧ぐ（中編� � - Google App Engine
1つのエントリにどのくらいの分量を詰め込むか？を考えるのは結構難しい。勿論、仕事の片手間でやっている作業なので1回で全てを片付けるのは無理なのだが、そもそも記事として読んでもらうのに適切な長さというものがありそう。あんまり長いと「あとで読む」扱いになって後はそのまま、、なんてコトになりがちなんじゃないだろうか。。。せっかくGoogle App Engine って面白いオモチャに興味を持ってくれた人がいるのに、それは少し残念。
もちろん、何かを学ぶ時に出来る限り楽しくするよう心がける事は出来ても、ラクにすることは無理な話なんだろうと思う。継続する為に自分のペースで好きに区切りをつけるのは受け手の自己責任って言っても良いのかも知れない。でも、せっかく起こった「ヤル気」を持続させる為に、自分に何か出来ないんだろうか？と考えずにはいられない。（まぁ、手っ取り早くGoogle App Engine のアプリが作れるようになりたいダケであれば、公式ドキュメントを見るより入門講座みたいなのを読んだほうが良いって説もあるので、濃い目な情報に触れたいって人がターゲットだ、って考え方を敢えてしてみるのもアリなのかも知れないけども）
なんて事を考えながら、今日も昨日のエントリに引き続きDatastore API についての超訳作業を続けていこうと思う。くどいようだが、あくまで超訳なので、ここにある事を全て鵜呑みにせず、必要に応じ原文をご確認願いたい。
あいさつ
やあ！待ってたよ。よく来たね！昨日の話はドウだったかな？ちょーっと概念的でイマイチだったかも知れない。まだどういう風にAPIを使うのか？全体も見れてなかったしね！ そんな君のために、今日はもうちょっと深いところまで攻め込んでみようと思う。期待しててくれよー！
データの生成、取得、削除
Datastore API を使ってモデルクラスのインスタンスであるエンティティを表現するってのは、昨日の話でイメージが掴めてるんじゃないかと思う。そこで、今回は実際のエンティティの作り方や編集のしかた、それに削除の方法、なんてあたりを紹介させてもらうゼ！
紹介していく順番はこんな感じになる！
- エンティティの生成と更新
- クエリを使ったエンティティの取り出し
- キーを使ったエンティティの取り出し
- エンティティの削除
それじゃあ早速いってみよう！
エンティティの生成と更新
繰り返しになるが、Modelクラス（とExpandoクラス）のインスタンスを使ってDatastoreのエンティティは表現される。横文字ばっか並んでるケドもう大丈夫だよな？ アプリケーションは新しいエンティティをModelクラスのコンストラクタを使って生成することが出来るんだゼ！ココでどんなものが生成されるかは、コンストラクタに結び付けられてるモデル次第になるケドな！
例えば、作り方はこんな感じだ！
pet = Pet(name="Fluffy", type="cat", owner=users.get_current_user())
だが、ここで安心しちゃわないでくれ！前にもいったと思うが、生成された当初はインスタンスがputされるまではdatastore上にはエンティティは存在していないんだ！だから、インスタンスのput()メソッドをコールするか、db.put()関数にインスタンス自身を引き渡すか、どっちかをやってdatastore上で有効な形にして欲しい！
つまりこんな感じだな！
# インスタンスのput()メソッドをコール pet.put() # db.put()関数にインスタンス自身を引き渡す db.put(pet)
ちなみに、既にDatastore上に存在しているインスタンスに対してput()メソッドを使った場合、上書き扱いになるゼ！ それからクエリの結果もモデルインスタンスとして返ってくるんだが、実はコイツ等も変更したりdatastoreに戻したりすることが出来るんだ！
例を見てみようか！
if users.get_current_user(): user_pets = db.GqlQuery("SELECT * FROM Pet WHERE pet.owner = :1", users.get_current_user()) for pet in user_pets: pet.spayed_or_neutered = True db.put(user_pets)
とりあえず、「作ったらput」、「作ったらput」と3回くらい繰り返してみてくれ！
ドウだい？ もう覚えたんじゃないか？
よし、それじゃあ次に行こう。
クエリを使ったエンティティの取り出し
Datastore API ではクエリが使えるってのは既に聞いてるよな？ クエリを使えばプロパティ値を使ったフィルタリングも出来るし、"ancestor"を利用してエンティティの範囲を制限する事だって出来るんだ！おっと、"ancestor" については昨日もちょっと出てきたと思うが、詳細については「キーとエンティティグループ」のセクションで深く説明させてもらう予定だから、ココではサラっと流しといてくれ！
そうそう、それからクエリがどんな風に使えるのか？ってのを詳細に知りたい場合は、「クエリとインデックス」のセクション（次回記事）を見てくれよな。何が出来て何が出来ないか、もう少し詳しい説明をさせてもらう予定だ！
で、実はDatastoreAPI で使えるクエリには2種類あるんだ。１つはQueryクラス。コイツはQueryオブジェクト上のメソッドを使うためのもんだ。そしてもう1つがGqlQueryクラス。コイツはSQLライクなクエリ言語であるGQLを使うためのもんだ。
それじゃ、QueryとGqlQueryと、それぞれを順番に説明していくぜ！
Query インターフェイス
Modelクラス（またはExpandoクラス）のall()メソッドは同種のオブジェクト全てのエンティティをQueryオブジェクトとして返却する形になってる！そしてアプリはfilter()、order()、ancestor()なんてメソッドを使って、そのQueryオブジェクトから必要なデータを取り出すコトが出来るゼ！
ちょっと例を見てみようか。
class Story(db.Model): title = db.StringProperty() date = db.DateTimeProperty() query = Story.all() query.filter('title =', 'Foo') query.order('-date') query.ancestor(key) # ちなみに上記のメソッドは連結して使ってもOK！ query.filter('title =', 'Foo').order('-date').ancestor(key)
言葉でいうとなんかややこしそうだけど、意外と簡単だろ？
GqlQuery インターフェイス
次はGqlQueryの方にいっていようか！
GqlQueryクラスのコンストラクタはGQLのクエリストリングとオプションパラメータを使うんだ。ちなみに「クエリストリング」ってのはデータの種別とかフィルタ条件とか、ソート順とか"ancestor"の条件なんかを入れ込むところな。コイツは出力結果の上限とかオフセットを含むことも出来るんだゼ！
ピンと来ないなら、まずは例を見てくれ！
# パラメータの使い方(ポジションで指定） query = db.GqlQuery("SELECT * FROM Story WHERE title = :1 " "AND ANCESTOR IS :2 " "ORDER BY date DESC", 'Foo', key) # パラメータとしてキーワードを使ってもOK query = db.GqlQuery("SELECT * FROM Story WHERE title = :title " "AND ANCESTOR IS :parent " "ORDER BY date DESC", title='Foo', parent=key) # 文字列、数字、真偽値なんかも使える query = db.GqlQuery("SELECT * FROM Story WHERE title = 'Foo' " "AND ANCESTOR IS :parent " "ORDER BY date DESC", parent=key)
それから、Modelクラスのgql()メソッドを使ってもOKだ。この場合、GQLクエリストリングとして「SELECT * FROM Model」の部分は省略されるから注意してくれよな！
query = Story.gql("WHERE title = :title "
"AND ANCESTOR IS :parent "
"ORDER BY date DESC",
title='Foo', parent=key)
ちなみに、bind()メソッドを使うことで一度取得したGqlQueryオブジェクトを再利用する事が出来るんだ！コレを使うと、１からGqlQueryオブジェクトを作ろうとするより早く処理できそうってのはイメージできるかい？結構ポイントになるとこだから、ちゃんとチェックしといてくれよ！
クエリの実行と結果へのアクセス
QueryオブジェクトもGqlQueryオブジェクトも、実はアプリがその結果にアクセスしようとするまではクエリを実行しないんだ。つまり、アプリが結果にアクセスしようとした時にクエリが実行され、Modelクラスのインスタンスとしてメモリに読み込まれるってコトだな。ちなみに、どっちのクラスも結果へのアクセス方法は２つある。1つがfetch()メソッドを使う方法、そしてもう1つがイテレータインターフェースだ。
fetch()メソッドは返却される結果の上限値を「fetch(上限値）」の形式で表現するぜ！それからオプションでスキップするオフセットを指定する事もできる。書き方としてはfetch(上限値, offset=オフセット値）って感じになる。上限値の部分で指定してるのが、datastoreから引っ張ってくる結果の数で、オフセットで指定するのが実際にメソッドの結果として返される結果の数ってコトになってるゼ！ 簡単にまとめると、まずはメモリ上に上限値までの全ての結果を引っ張ってきて、それから初めてオフセットに従った結果を返す為の処理が行われるってワケだな。つまり、オフセットで指定する値はdatastoreからとってくる結果の数には影響を与えなくて、あくまでもfetch()メソッドの実行結果を返す段階で使われるダケって話だ。
fetch()メソッドの使い方はこんな感じになる。
results = query.fetch(10) for result in results: print "Title: " + result.title
fetch()メソッドの引数として指定された上限値やオフセット値は、GQLクエリストリングの中で与えられた上限値やオフセット値を上書きするようになってるぜ！注意してくれよ。クエリオブジェクトがイテレータ（反復子|繰返子）として利用される場合は、クエリは上限値やオフセット無しで実行されるんだ。そして結果はメモリに読み込まれ、Modelクラスのインスタンスとして返されるワケだな。
for result in query: print "Title: " + result.title
ちなみに、App Engine サービスのシステム側で規定している上限値ってのがあって、fetch()メソッドで指定できるのは1000までになってる。上限を指定しなかったり、それを超えてたりする場合は、1000が指定されてたものとして扱われるから、そこは気をつけておいてくれっ！
じゃあ、次はキーを使った場合について見ていこうか。
キーを使ったエンティティの取り出し
Datastoreにエンティティが保存されると、エンティティは個々にユニークなキーを持つって話は昨日したよな？このキーってヤツはKeyクラスのインスタンスとして作られるもんなんだ。put()メソッド とかdb.put()関数なんかを使った場合に返却されてくるゼ！ そしてエンティティがDatastoreに保存された後は、key()メソッドを使えばいつでもそいつのキーを取得ことができるんだ！
今の話の流れをコードで見るとこんな感じだな！
entity.put()
key = entity.key()
# ...
entity = db.get(key)
キーのよくある使い方としては、他のエンティティのプロパティに格納するってのがある。ReferencePropertyモデルのpropertyクラスは自動的な参照機能が使えるから、プロパティにモデルのインスタンス自身を格納したい場合は、直接指定したって構わないんだ！うぉーっ！こりゃ便利！！
つまりこういうこと。
class Pet(db.Model): name = StringProperty() owner = ReferenceProperty(PetOwner) class PetOwner(db.Model): name = StringProperty() owner = PetOwner(name="Albert") pet = Pet(name="Fluffy", owner=owner) # コレは上の行と同じことを意味する pet = Pet(name="Fluffy", owner=owner.key())
ま、どっちが書きやすいか？って話かも、だな。
同様にこんな使い方もあるぜ！
pets = GqlQuery("SELECT * FROM Pet WHERE name = :1", "Fluffy")
pet = pets.get()
owner_name = pet.owner.name
ちなみに、Expndoを使ったダイナミックプロパティやListProperty要素なんかにあるキーについては、この自動の間接参照は使えないから気をつけてくれよな。ReferencePropertyだけがコレを使えるってコトだ。
db.get()関数を使ってキーを指定すれば、datastoreから該当データを引っ張ってくることが可能だぜ！キーはアプリケーション外に出す場合の事を考えて文字列にエンコードすることも可能になってる。エンコードされたキーをKeyオブジェクトに戻す為には、その文字列をKeyコンストラクタに引き渡せばOKだ！
obj = MyModel(name="Foo") self.response.write('<a href="/view?key=%s">%s</a>' % (str(obj.key()), obj.name())) # ... key_name = self.request.get('key') obj = db.get(db.Key(key_name))
ただ、エンコードって言っても暗号化してるワケじゃないからな。キーの中身をちゃんと守りたければ、別途暗号化とかを考えるようにしないと駄目だ。そこは気をつけてくれよ！
＃ え？ お前は暗号の実装に詳しいだろうって？ 希望が多かったら何かオープンソース化とか考えてみるカモな！
それじゃ、次はいよいよデータを削除する場合についてだ！
エンティティの削除
アプリはエンティティを消したい場合、モデルインスタンスを使うか、キーを使えばOKだ。モデルインスタンスのdelete()メソッドは対応するデータをdatastoreから消してくれるぜ！ちなみに、delete()関数の場合はキー（またはキーのリスト）を引数に使ってdatastoreからエンティティを削除する形になってる。
例で見てみようか。
q = db.GqlQuery("SELECT * FROM Message WHERE create_date < :1", earliest_date)
results = q.fetch(10)
for result in results:
result.delete()
# db.delete() の呼び出しで引数となるエンティティは全て同じエンティティグループになければならない。
# そうすれば全ての削除処理が１つのトランザクションの中で発生させられる。
q = db.GqlQuery("SELECT * FROM Message WHERE create_date < :1" +
"AND ANCESTOR IS :2",
earliest_date, parent)
results = q.fetch(10)
db.delete(results)
そうそう。エンティティを削除しても、他のエンティティでそのエンティティを参照するのに使っていたキーの値には何の影響も発生しないぜ！つまり、消されたエンティティのキーを間接参照する可能性がある場合、アプリはアクセスの前にdb.get()を使ってエンティティが存在してるかをチェックした方がイイってコトだな。
ただ、"ancestor"を削除したとしても、他のエンティティには影響は無いぜ！アプリがエンティティのキーを作るのに"ancestor"の存在を前提とするようなことが無い限り、アプリは"子孫"にあたるエンティティにアクセスし続けられるってコトだ。これはイメージとしてちょっとややこしいかも知れないから気をつけておいてくれよ！
それじゃ、次にいってみようか！
キーとエンティティグループ
Datastoreに存在する全てのエンティティはキーを持ってるって話はすでに理解してるよな？コイツは各エンティティのユニークな識別子としてアプリケーション側で利用されるもんだ。そして、キーっていっても実はいくつかの部品によって成り立ってるんだ。例えばパスってのはエンティティ間の親子関係を示すもんだし、他にエンティティの種別、そしてアプリによって与えられた名前か、数字で構成されるID（datastoreに割り振られたヤツ）なんてのがあるな。
それじゃ、順番に説明させてもらうぜ！流れはこんな感じだ。
- 種別、名前、ID
- エンティティグループ、"ancestor"、そしてパス
- パスとキーの一意性
用意はいいかい？
種別、名前、ID
全てのエンティティは種別ってもんを持ってるんだ。昨日も説明したと思うが、要するにはオブジェクト指向でいうところのクラスみたいなもんだな（この場合、エンティティはインスタンスってコトな）。で、コイツはクエリで使える。ちなみに、データベースのテーブルと違って同じ種別のエンティティだからって同一のプロパティを持たないといけないなんてコトはないんだぜ！ってこれはもう何度か言ってるな。ただ、アプリとしては敢えてそういう制限をつけるのもアリなんだろうと思うゼ！とにかくdatastore API はModel(またはExpando）クラスのサブクラスの名称を種別名として利用するんだ。
例えば、以下の例だと種別に"Story"ってのを与えられたモデルを規定してるゼ！
class Story(db.Model): title = db.StringProperty() author = db.StringProperty()
で、全てのエンティティはIDを持ってる。アプリは自分でIDを割り振ることが出来るんだ。その場合は、引数としてkey_nameを使ってインスタンスのコンストラクタを呼び出せばイイ。あ、ちなみにここで使えるのは文字列型(str)ダケな。注意してくれ。
s = Story(key_name="xzy123")
そしてアプリが名前を与えなかった場合は、保存時にdatastoreから自動的に数字のIDが割り振られるんだゼ！
つまりこういうことだ。
s2 = Story() # s2 はこの時点では名前もIDも持たない s2.put() # s2 このタイミングでdatastoreからIDが割り振られる
それから、いったん名前なりIDなりが決まるとそこは変えられないから気をつけてくれよ！
あと、ちょっとした小技を教えとくな。キーの名前やIDってのはクエリではプロパティ値みたくは使えないんだが、自分で名前をつける場合なんかは、それを別途プロパティに保存しとけば似たようなことは出来るぜ！実は数字のIDにしてもまあ同じようなコトができなくもない。Obj.key().id()を使ってIDを取り出せば、そいつを別のプロパティに保存しとけば良いワケだからな！ まぁ、使えねーとか文句言う前に抜け道ないか考えろ、ってコトだ。
エンティティグループ、"ancestor"、そしてパス
実は、どんなエンティティにしたって何かしらのエンティティグループの一員なんだ。エンティティグループってのは、同一のトランザクションの中で一括して処理が出来る1つ以上のエンティティの集まりみたいなもん、って言えばいいかもな。App Engine は分散ネットワーク上の環境を使ってるから、同じエンティティグループに属しているものは、同じところに保存しておいた方が何か処理をするのに効率が良さそうだってのは思わないかい？トランザクションってのはエンティティグループの為のdatastore操作の組み合わせのコトで、この処理は成功した場合はグループの全てのエンティティに対して適用され、失敗した場合は全ての処理がなかったことになる、って仕組みになってる。この話は何度か既にさせてもらってるよな？
それから、アプリがエンティティを生成した時には、他のエンティティを親エンティティとして割り当てることが出来る！そして親エンティティを割り振るってコトは、新しいエンティティを親エンティティと同じエンティティグループに所属させる、ってコトを意味するんだ！
ちなみに親を持たないエンティティはルート(root)エンティティって呼ばれるんだ。そして、何かの親になってるエンティティ自身も、親エンティティを指定することが出来るんだゼ！実は、このRootまで連なる親子の連鎖のコトをパスって呼んでるんだ！そして、パスに含まれる各メンバ（要は親エンティティ達だな）のことを、エンティティの"ancestor"って呼ぶことになってる。ああ、それからエンティティの親ってのはエンティティが生成された時に決められるもんで、後で変更はきかないから注意してくれよ！
そしてここは君にも想像つくと思うんだが、同じルートを先祖に持つ全てのエンティティは同じエンティティグループの一員って扱いになるんだ。ってコトは、そいつらは同じdatastoreノードに保存さえるってコトになるな。こうしとけば、1つのトランザクションで同一グループの全てのエンティティに対して変更したり、そこにエンティティを追加したりって処理が出来るだろ？ つまり、分散データベースだから効率的に使うにはドウとか、そういう小難しい話は俺たちは気にしないでイイってワケだ。かーっ！やるよなー、Google。君はそうは思わないかい？
さて、トランザクションについての詳しい話は後でさせてもらうから、ここではこの辺にしておくぜ！
それから、何かのancestorになってるエンティティが削除された場合なんだが、別に子孫まで削除されたりすることはないぜ！パスを使うなり、キーを使うなりしてちゃんとアクセス出来るようになってるから安心してくれ！
あと、コイツはちょっとトリッキーな話かもしれないんだが覚えておいて欲しい。実は、先に親となるエンティティを作らなくても、ancestorを持った状態でエンティティを生成することが出来ちゃうんだ！ これはただの順番の問題だから、そうしたい場合はちゃんとancestor用に種別とキー名を考えてつければイイ話なんだけどな。
繰り返しになるが、同じルートをancestorに持ってる全てのエンティティは同じグループの一員だぜ。これはパスで示されるルートが実際のエンティティであろうがなかろうが一緒の話ってところ、覚えておいてくれよ！
その他の小技（心得4箇条）
- トランザクションに必要な時だけエンティティグループは使うべし。その他のエンティティ間に関わる処理については、クエリで利用可能なReferencePropertyとキーを利用すべし。
- より多くのエンティティグループは、より多くのルートエンティティの存在を意味する。これは、より効率よく分散datastoreを利用することにつながる。上手くデータを分散させることは、データの生成や更新におけるパフォーマンスの向上につながるものである。さらに、複数のユーザがデータ操作を同時に行った場合のことを考慮し、データの変更エラーに伴うリトライ回数を低減させるため、全てのエンティティが同一のルートを持つような状況は避けるべし。
- 経験則上、エンティティグループは1人のユーザ分のデータに相当する程度か、それ以下に抑えるべし
- エンティティグループは、クエリに対して特に大きな影響は与えない。過度の意識は捨ててよし。
パスとキーの一意性
エンティティのキーの構成ってヤツをよく見てみると、実際のところ「パス」だの「種別」だの「名前（または数字のID）」だのあるワケだが、こいつは各エンティティで固有のものになるってのはすぐ分かるだろう？ そして、このキーの完全体はエンティティがdatastore上に生成されたタイミングで割り当てられるもので、どの部分も後で変えられるもんじゃないだ。まぁ、考えてみれば当たり前の話だよな。
ちょっと２つの異なるエンティティのキーの差分について考えてみようか？ 結論から先にいえば、似たようなパーツを持てたとしても、最低1箇所は違うようになってるんだ。例えば、2つのエンティティは同じ種別と名称を持つことが出来る。でも、この場合は親が別じゃないと駄目だな。同様に、同じ親（または親ナシ）と同じ名称を持つことも出来る。でも、この場合は種別が別じゃないと駄目だ。
それから、エンティティを生成する度にIDに使われてる数字がずっと増え続けていくもんだとは決め付けない方がイイぜ！一般的にはそうなんだが、別にGoogle側がそれを保証してるワケじゃないからな！こういう落とし穴、結構ハマるやついるから気をつけようぜ！
おっと、そろそろ今日も時間が来たみたいだ。
明日のエントリーを期待しててくれよーっ！
締め
作業していて気付いたのだが、実はこの「深夜通販番組風」の語り口に変換する作業が一番時間がかかっていたりする。。。多分、普通よりもリズムを考えたりしないと駄目なのと、APIの説明に「褒める系」「Googleスゴイな！系」のネタを入れ込むのがそもそも難しいからなのだろう。。 そろそろ鬼教官に登場してもらった方が楽なのかも知れない。アレは結構楽に筆が進むので。。。でも、、アレ？って事は自分がそういう側面を持ってるってコトになるのか知らん・・？
これはフローと言えるのか？
日々の雑感とか | | 
最近のエントリーを見れば分かる通り、ここのところは、ずっとGoogle App Engine の超訳に集中している。あれ、暗号はドウした？数学はドウした？というくらいの勢いだ。
以前、梅田望夫さんがRubyの松本さんへ行ったインタビューに関連した記事か何かで「オープンソースコミュニティの人達は何故、無償でプログラミングに取り組むのか？」といった話が出ていた。その中で松本さんは「人々は概ね自分の能力にちょうどあった困難さに取り組める機会を常に求めているものだ」といった類のコメントをされていたのを思い出した。その記事を読んだ当時は「コレってチクセントミハイのフロー理論ってヤツだよなー」なんて程度のコトしか考えなかったのだが、今自分が取り組んでいるのも結構それに近い話なのかも、、なんて思ったり。
確かに超訳にはハマってる。でも、よくよく考えると何でだろう？ 会社で人の為に翻訳とかしてあげたコトなんてないし…
- 人に説明しようとする事で注意深く読もうとする。それが勉強になってるから
- 公開しておけば誰かがツッコミを入れてくれ、更なるレベルアップにつながるカモ？
- なんだかんだ言っても結構評判が良くて嬉しいから
- 誰もやってないみたいだから、このまま取り組めばトップグループに入れるカモ？
- 大量のGoogle App Engineプログラマ誕生のきっかけを作り、某プロレスラーのように「日本人は本当はスゴいんです！」とか言ってみたい？
- そもそも教えるってコトに凄く興味がある
こんなところだろうか…
別にアフィリエイトをしてるワケでもなし、このブログのアクセス数が上がろうと上がるまいと本質的にはどうでも良い。むしろ会社の同僚に見つかると面倒なので、ホドホドが良い。そう思っていたハズなのに、実際に大量にアクセスが来るとやっぱり嬉しい。アクセスが少ない記事は、ちょっと切ない。
人間の心ってのは実に難しいもんだなー、と改めて思った4月の夜。
