GoogleAppEngineのトランザクションをねじふせる

前のエントリーで書いたように、GoogleAppEngineのトランザクションは使い勝手が悪い。しかし、GAEにブログを移行しようと思うとこれは乗り越えなければならない。

GAEでトランザクションを行う条件を簡単にまとめると

  • db.run_in_transactionにトランザクションとして実行したい関数を渡すがその関数内では
  • 同じエンティティグループに属しているモデルで
  • get, put, deleteのみ

しか実行できない。なのでトランザクションのページに紹介されているような

python code
  1. from google.appengine.ext import db
  2.  
  3. class Accumulator(db.Model):
  4.   counter = db.IntegerProperty()
  5.  
  6. def increment_counter(key, amount):
  7.   obj = db.get(key)
  8.   obj.counter += amount
  9.   obj.put()
  10.  
  11. q = db.GqlQuery("SELECT * FROM Accumulator")
  12. acc = q.get()
  13.  
  14. db.run_in_transaction(increment_counter, acc.key(), 5)
  15.  

先にGQLを発行しておいて、run_in_transactionに渡す関数ではGQLの結果として取得したkeyを引数にとる、という回りくどいコードになる。コレは書きづらい。

これも前のエントリーに書いたように、今回作ったブログアプリでは月別アーカイブやタグアーカイブの記事数をエントリのCRUD時に操作している。

エントリ作成時なら

python code
  1.   @classmethod
  2.   def create(cls, *a, **k):
  3.     obj = super(Entry, cls).create(*a, **k)
  4.     TagCount.inc(obj.status, *obj.tags)
  5.     MonthCount.inc(obj.status, obj.created_month)
  6.     return obj
  7.  

というような感じだ(statusは公開、とか非公開とかが入る)。当然、このcreateメソッドではTagCount,MonthCountとobjについて一貫性が保たれなければならない。しかし、TagCount.incでは対象のタグを検索して、なければ作成しputする、という操作を行う。「対象のタグを検索して」というトランザクション内で許可されていない操作が入っているのだ。

さて、こういうときはとりあえず？力技で乗り切ろう。かなり強引だが、下のようなコードで乗り切ってみた。一応、サーバにアップロードして動作することは確認している。

python code
  1. class RootModel(db.Model):
  2.   id = db.IntegerProperty(default=1)
  3.   def __call__(self, k):
  4.     v = k or {}
  5.     v.update(parent=with_parent)
  6.     return v
  7. with_parent = RootModel.get_or_insert("id", id=1)
  8.  

まず、全てのエンティティを同一エンティティグループに所属させることにする。そのため、全てのエンティティの親となるエンティティを作成する。

次は強引さの根源のようなクラスだ。

python code
  1. class Transaction(object):
  2.   MAGIC_NAME = "__magic__lst__"
  3.   SEARCH_MAX = 12
  4.   def __init__(self, f):
  5.     self.f = f
  6.  
  7.   def execute(self):
  8.     __magic__lst__ = []
  9.     result = self.f()
  10.     def commit():
  11.       for dbop in __magic__lst__:
  12.         dbop()
  13.       return True
  14.     committed = db.run_in_transaction(commit)
  15.     if committed is None:
  16.       raise db.Rollback()
  17.     return result
  18.  

これだけでは分からないと思うが、execute内でrun_in_transactionが実行されている。その引数にはcommit。commitの中では__magic__lst__というリスト内の関数を実行しているようだが、__magic__lst__に要素が追加されている形跡がない。

そして、全てのモデルの親となる基本モデルを定義する。

python code
  1. class BaseModel(db.Model):
  2.   @classmethod
  3.   def create(cls, *a, **k):
  4.     obj = cls(*a, **with_parent(k))
  5.     obj.put()
  6.     return obj
  7.  
  8.   def _with_transaction(self, name):
  9.     i = 1
  10.     f = sys._getframe(i)
  11.     while f and i < Transaction.SEARCH_MAX:
  12.       if Transaction.MAGIC_NAME in f.f_locals:
  13.         f.f_locals[Transaction.MAGIC_NAME].append( \
  14.           lambda : getattr(super(BaseModel, self), name)())
  15.         return
  16.       i += 1
  17.       f = sys._getframe(i)
  18.     return getattr(super(BaseModel, self),name)()
  19.  
  20.   def put(self):
  21.     return self._with_transaction("put")
  22.  
  23.   def delete(self):
  24.     return self._with_transaction("delete")
  25.  
  26.   def update(self, **k):
  27.     for prop in self.properties().values():
  28.       if prop.name in k:
  29.         prop.__set__(self, k[prop.name])
  30.     self.put()
  31.  
  32.   @classmethod
  33.   def get_by_id(cls, id):
  34.     return super(BaseModel, cls).get_by_id(id, parent=with_parent)
  35.  

この基本クラスではまず、createというメソッドを定義し、エンティティはすべてこのメソッドを通して作成するようにしている。createでは必ず親エンティティとしてwith_parentを指定する。これにより全てのエンティティは同一エンティティグループに属することになる。

  • 同じエンティティグループに属しているモデルで

という条件はクリアしたことになる。次は

  • get, put, deleteのみ

という条件だ。これは_with_transactionというメソッドでクリアしている。putとdeleteをオーバーライドして_with_transactionを呼び出すようにしている。さて、この_with_transactionではフレームをさかのぼって、__magic__lst__という名前のローカル変数が存在するフレームがないか探索する。そのフレームが存在した場合、一連のトランザクション内での実行とみなし、__magic__lst__にput,deleteを行うthunkを登録し、終了する。存在しない場合は通常の実行ということで、その場でput, deleteを行う。つまり、トランザクション内で実行されたことを検出してput, deleteの評価を遅延させるのだ。

さきほどのcreateは

python code
  1.   @classmethod
  2.   def create(cls, *a, **k):
  3.     def _():
  4.       obj = super(Entry, cls).create(*a, **k)
  5.       TagCount.inc(obj.status, *obj.tags)
  6.       MonthCount.inc(obj.status, obj.created_month)
  7.       return obj
  8.     return Transaction(_).execute()
  9.  

と若干のコード挿入のみできちんと一貫性が保証されるようになる。

というわけで、かなり強引な気がするけどトランザクションの問題は一応クリアされた。めんどくさければHTTPリクエストを受けてから、レスポンスを返すまでを関数でラップし、Transaction.executeすれば大丈夫だ。

ここまでやってしまったので、やっぱり今のブログはGAEに移行しようかなあ、と思い始めたり。デザインも今と似ているけどやっぱ一から自分でマークアップしたから好みだし、なによりXHTMLとしてValidだ。機能的にはあと、スパム対策さえあれば大丈夫。

実はOpenIDも自分でサーバ立ててたりするので、それもGAEで実装しなおしたいなあとか色々やりたいことは尽きない。GAEでの開発はこのモデルの問題さえつぶしてしまえばかなり楽だし、夢がひろがるなあ。

07.27.08/12am
Posted at:
07.04.08/02am
Tags:
Comments:
0
Permalink

GoogleAppEngineのモデルをいじってみた

なんの幸運か、Softbank（しかもJ-phone時代からの）ユーザだったので、SMS認証もアッサリ通ってGAEのアカウントをゲットしたわけですが･･･（ただしiPhoneには興味ほぼなし)。

というわけでishikawaさんがブログをGAEに移行された、というのを知って俺も移行しようかなあとか思いつつブログアプリ作りました。すでに今ブログで使っている機能は全て実装済みだったりします。デザインも全頁XHTMLTr validでCSSもvalidなことを確認済みだったりします。しかもDjangoじゃなくてweb.pyだったりします。慣れてるしね。

それはおいといて、データストアまわりがそのままだと

  • filter("hoge =", value)が長ったらしい
  • CRUDが微妙。
  • フォーム作成用等に空のモデルを一時的に作成したいけど、作成した時点でvalidateされるので作成できない

らへんがいまいちだったで、ちょっといじってみました。

python code
  1. def _getattr(self, name):
  2.   if name.endswith("_eq"):
  3.     return lambda v: self.filter("%s ="%name[:-3], v)
  4.   raise AttributeError(name)
  5. setattr(db.Query, "__getattr__", _getattr)
  6.  
  7. class ModelMixin(object):
  8.  
  9.   default_order = None
  10.   _stab_class = None
  11.  
  12.   @classmethod
  13.   def stab(cls):
  14.     if not cls._stab_class:
  15.       stab = type('Stab%s'%cls.__name__, (cls,), dict())
  16.       for k,v in stab._properties.iteritems():
  17.         v.required = False
  18.         v.choice = None
  19.         v.validator= None
  20.       cls._stab_class = stab
  21.     stab = cls._stab_class()
  22.     for k,v in stab._properties.iteritems():
  23.       v.__set__(stab, v.default_value())
  24.     return stab
  25.  
  26.   @classmethod
  27.   def create(cls, *a, **k):
  28.     obj = cls(*a, **k)
  29.     obj.put()
  30.     return obj
  31.  
  32.   @classmethod
  33.   def find_all(cls):
  34.     result = cls.all()
  35.     if cls.default_order is not None:
  36.       return result.order(cls.default_order)
  37.     return result
  38.  
  39.   def update(self, **k):
  40.     for prop in self.properties().values():
  41.       if prop.name in k:
  42.         prop.__set__(self, k[prop.name])
  43.     self.put()
  44.  
  45.   def destroy(self):
  46.     self.delete()
  47.  

これで

python code
  1. class Test(ModelMixin, db.Model):
  2.   name = db.StringProperty(require=True)
  3.   created_at = db.DatetTmeProperty(auto_now_add=True)
  4.  
  5.   default_order="-created_at"
  6.  
  7. Test.find_all() # created_atの降順
  8. Test.all().name_eq("user").update(created_at = datetime.now())
  9. stab = Test.stab() #nameがなくても作成できる
  10.  

こんな感じにかけます。

さて、そんなこんなでブログアプリを作ったのはいいんだけど、なんとなく移行する気にならない。現在はWordpressで運用しているけど、正直セキュリティホールは多いし、ソースコードを見ると泣きたくなるようなコードだし、頻繁なバージョンアップはめんどくさい･･･。プラグインのセキュリティホールまで考えるとなおめんどくさい。しかもそこまで機能を使い倒しているわけじゃないし。

だからGAEにでも移行したいんだけど･･･。データがGoogleに握られるのはそこまで心配じゃない。ブログサービスでブログをやれば、そのブログサービス事業者にデータを握られるってのと同じだから気にならないんだな。移行作業自体も記事数がかなり少ないのでそんなにめんどくさそうではない。

ひとつ引っかかっているのはトランザクションの問題。まぁめったにトランザクションで問題はおきないと思うけど、GAEのトランザクションは一応ある、といった程度でほとんど使えない。使おうとしたらtransactionの中でこれはしちゃだめ、これもしちゃだめ、とおこられまくったので現在トランザクション管理ができていない。GAEには集約系のメソッドがないので、月別記事数とか、タグ別記事数とかを記事のCRUD時に別モデルで管理しているわけだけど、ここのトランザクションが管理できないのは結構不安。

もうひとつはなんとなーく使い切らないんだけど無料の上限である500Mという容量が微妙。画像のアップとかしなけりゃまず大丈夫なんだけど。

その他にもなんとなくGoogleの罠じゃないかとかいろいろ気になって移行に踏み切れないでいる今日この頃。実際に本格的にGAEに移行した人の感想がききたいなあ。

07.27.08/12am
Posted at:
06.30.08/11pm
Tags:
Comments:
(2)
Permalink

Python版Yahooテキスト解析 APIライブラリをかな漢字変換に対応させました

まぁ需要はないと思うんですが一応。内部的にはWebService::Simpleみたいになってるんでサクッと対応できます。

ダウンロード

yahooapi

使い方

python code
  1. import yahooapi.jlp as jlp
  2.  
  3. client = jlp.JIMServiceAPI("your_apikey")
  4. result = client.conversion(sentence=u"かなかんじへんかんたいしょうのてきすとです")
  5. for i in result.Result.SegmentList.Segment[0].CandidateList.Candidate:
  6.   print i
  7. #=>
  8. #かな
  9. #佳な
  10. #仮名
  11. #カナ
  12. #ｶﾅ
  13. #加奈
  14. #可奈
  15. #佳奈
  16. #香奈
  17. #香菜
  18. #華奈
  19. #花奈
  20. #哉
  21. #金
  22.  

うむ。

07.27.08/12am
Posted at:
05.28.08/08pm
Tags:
Comments:
0
Permalink

About

Author:yuin(http://inforno.net/)

文学部文化学科卒という生粋の文系趣味プログラマ。

主にRuby、Javascript、PHP、JAVA,Python,C,Scala,Schemeなどを使っています。今はPythonな感じかもしれない。今後作曲活動なども復活するかもしれない。

Links

Pages

Recently

Tags

DHT1 SF1 activesupport1 api4 binary3 blog1 book1 cltc1 compiler1 craftlaunch2 cui1 development9 drecom1 electronics1 emulator6 erlang1 essay10 fckeditor1 feed1 framework1 gae3 go1 gui2 javascript14 job4 kademlia1 language2 library14 life5 lingr1 linux1 nes5 network1 nicovideo1 nlp1 ocaml1 p2p1 parser6 programing2 prototype_js7 python39 python30001 rayphe1 ruby5 rubyonrails2 scala6 scheme1 scrap1 scriptaculous1 sexp1 tasktools1 template3 text3 tk1 typo2 vim2 webpy2 windows4 wordpress2 xrea2 yahoo4

Monthly Archives