CouchRest について

http://www.kurano.jp/blog/sadayuki/2009/05/18/couchrest-%E3%81%8C%E9%9D%A2%E7%99%BD%E3%81%84%E4%BB%B6

merb に興味のある方であれば、DataMapperのCouchDB bindingも面白いと思います。それはそれとして、CouchRestについて、実際に結構使ったことがあるので、そのときの感想。最近は全然さわれてないので、半年前ぐらいのバージョンのやつです。

まず、CouchRestはすごい使いやすいと思っているので、先に、だめだなぁ、と思ったところ。

  • propery :foo というのは、正直微妙。どうせなら string :foo, number :foo とかにしたい。JavaScript は暗黙の型変換が結構めんどくさいのでRuby側で型変換はさせたかった。
  • 同時に、validates_length_of とかその辺の関数がほしい。:before_save とかも。

というわけで、http://github.com/yssk22/couch_resource/tree/master を作ったりしました。が、正直労力の割に受けられる恩恵が少ない。こういうものに興味がなくなったのでおすすめはしません。

何となく何が良いのか分からなくなるような気がしないでも無い

自分でもActiveRecordライクに作ってみて、その後でCouchAppをさわってみたら、CouchAppに感動して、もうRailsいらねーや、と気づかせてくれた、という意味では、ORMなどに慣れ親しんでしまった若者がCouchDBを楽しむには一回通っておくべき道なのかもしれません。私自身は、もう、CouchDBでは、こういうMapperを使う気にはならなさそうです。

あと、ビューについて。view_by はいいんだけれど、ビューに登録するときに クラス名-ビュー名-ビューの文字列のMD5値 で登録するような仕組みになっている。何回もプロセスを再起動すると、そのたびにMapReduceが作られる。ぶっちゃけ、毎回クリーンアップしないと(クリーンアップ用のメソッドがあったはず)、デバッグするときに、「最新版のデザインドキュメントはどれー?」という状況になって死ねる。データがたまってきて、10万件ぐらいを超えると、デザインドキュメントから生まれるキャッシュのサイズも馬鹿にならないので、その当たり運用が面倒。

どうでもいいことですが、view メソッドの呼び出し時にブロックを与えると、Rubyからcurlを叩いて、標準入出力をストリーム処理する様な動きをします。これはこれで、メモリの節約には使えるのでいい試みかもしれませんけど。

で、いいところは、、、CouchDBのマッパーの中では、CouchDBの中の人で、Rails/Ruby好きが作っていることもあって、最新版のCouchDBへの対応が早い点。forkも多いので、結構つぶしがききますね。

あと、使うのだったら、view_by も少し書き換えて、RubyのView Serverを用意して、Rubyのみでやったほうがいいように思ってたりもしてます。

ついでに。

ちなみに某所のCouchDB記事がRubyベースで書いてあるのは、、、という裏話。

さすがに、Java でライブラリを別途インストールせずにHTTPやろうと思ったら思いのほか大変で(笑、さすがにC# (WebClient) はなぁ、と思ったのと、PHPは楽だけど嫌いだ、Pythonも標準だとPUT/DELETEに困ったりする、と。sh/curlwiki作るには、昔、sh でかかれたhttpdとか見たような記憶があるけれど。。