読者です 読者をやめる 読者になる 読者になる

protocol bufferでmakeSyncCallする getIndices編

あれからしばらくたっていろいろ試してみたのですが、やっぱり成果はありません。なんか、中の構造が見れて楽しげであることと、ちょっとだけ悪いことをしているような背徳感があるのがいい感じ、ということで、この辺は趣味の領域なのでしょう。

今日はインデックスを取得することにしました。インデックスには、kind index/single property index/composit indexの三種類がありますが、makeSyncCallで取得できるのはcomposit indexのみです。

ある意味では、kind indexとsingle property indexはschemeのデータであるようにも思え、getSchemeだけできないのはいまいち納得がいきませんが、そこは大人の事情ということでしょうか。


makeSyncCallするときにめんどくさいのが、どういうメソッドが呼べるのかそもそもよくわからん、というところでソースを追っかけるところです。引数が正々堂々とstringなので。

ということで、はやりのgoogle codeに簡単なユーティリティを乗っけておきました。

http://code.google.com/p/balmysundaycandy/source/browse/trunk/balmysundaycandy-morelowlevel/src/balmysundaycandy/more/low/level/DatastoreOperation.java

morelowlevelというのは、おそらく日本人で初めてmakeSyncCallするサーブレットを作った偉大なる先人がおっしゃっていたので、パクりました。ソースは、makeSyncCallしたいひとには参考になるかもしれません。

(本当にめんどくさいのは、行きのprotocol bufferオブジェクトを組み立てるところです。まだ組み立てのサポートは実装していないので、そこは大人の事情ということで目をつむってください)


ではつかってみます。

StringProto request = new StringProto();
request.setValue(APPID);
CompositeIndices response = DatastoreOperations.GET_INDICES.call(request);

組み立てがapprication idだけでいいなんて、わかりやすくていいですね。

responseを表示してみると、

index <
app_id: "あなたのアプリケーションのIDです!"
id: 1
definition <
entity_type: "TEST"
ancestor: false
Property {
name: "name"
direction: 1
}
Property {
name: "age"
direction: 1
}
>
state: 1
>

こんな感じですね。

direction:1はascです。試してないですがdescは2になるんじゃないかと思います。
state:1 はbuildingで、servingになると2になります。

ancestorがみれるところが肝かと思わないこともないですが、それって設計時点でわかってるんじゃないかと。。
デプロイ後にstateを参照して稼働可能かどうか判断する、という方向でなら、使いどころはあるのかもしれません。