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

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

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

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

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

PLAIN TEXT
PYTHON:
  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)


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

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

エントリ作成時なら

PLAIN TEXT
PYTHON:
  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


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

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

PLAIN TEXT
PYTHON:
  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)


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

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

PLAIN TEXT
PYTHON:
  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


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

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

PLAIN TEXT
PYTHON:
  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)


この基本クラスではまず、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は

PLAIN TEXT
PYTHON:
  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()


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

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

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

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

Posted at 2am on 07/04/08 | no comments | Tags : read on

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

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

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

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

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

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

PLAIN TEXT
PYTHON:
  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()


これで

PLAIN TEXT
PYTHON:
  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がなくても作成できる


こんな感じにかけます。

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

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

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

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

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

Posted at 11pm on 06/30/08 | 2 comments | Tags : read on

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

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

ダウンロード

yahooapi

使い方

PLAIN TEXT
PYTHON:
  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. #金


うむ。

Posted at 8pm on 05/28/08 | no comments | Tags : read on
Pages (22): [1] 2 3 4 » ... Last »

About

about me
yuin()
文学部文化学科卒という生粋の文系趣味プログラマ。
ベンチャー企業でアルバイトを経て、某大手企業で働いてます。 　　　
主にRuby、Javascript、PHP、JAVA,Python,C,Scala,Schemeなどを使っています。
今はPythonな感じかもしれない。今後作曲活動なども復活するかもしれない。

Pages

Recently

Monthly Archives

Tags