_bulk_docs と all_or_nothing
_bulk_docs は 0.8 から追加された機能で、そこに0.9.0 からall_or_nothingオプションが追加されました。all_or_nothing を使うと、ドキュメントのrevチェックを回避して強制的に競合状態を作り出すことができるように見えます。が、最新のtrunkでall_or_nothingがドキュメントを削除するときに意図したとおりに動作していないように見えてはまっております。
再現はできそうなので、 明日svn logを眺めて再現テストを書いてMLに投げる!
データベースがOAuthを話すなんて、なんて画期的なんだ。
とは思わなかったのだけれど。これで認証、認可が一通りできるようになりそうです。
CouchDBの0.10? あたりから追加される機能で、trunkのバージョンはすでに0.11のストリームになっているのでtrunkで機能を確認できます。
詳細は明日あたり書こうかと。
ドキュメント指向的銀行トランザクション
_bulk_docsがでてきたのでついでに。データベーストランザクション、というと銀行の口座があるわけですが、
- Aさん、Bさんの口座をロック
- Aさんの口座残高 = Aさんの口座残高 - 10万円
- Bさんの口座残高 = Bさんの口座残高 + 10万円
- 全部実行できることを確認してコミット。
ってやつですね。この辺の話はgoogle://"口座"+"トランザクション" あたりで調べてもらえれば腐るほど出てくるのですが、 Aさんは「今からトランザクションするぜ！」といって、その上、Bさんの口座に振り込むために、Bさんの口座をロックするのです。なんと迷惑な！勝手に他人の口座をロックするなんて！と思わないのかなぁ。
CouchDBをはじめとしたドキュメント指向データベースでは次のようにすればいいでしょう。
- Aさんは銀行宛に「Bさん宛振り込み10万円、Aより」とかいた紙を渡します
{
doc_type: "振り込み"
from: "A",
to: "B",
amount: 10
}
これを保存する。
以上です。身も蓋もないですが、これだけです。これでアプリケーションが作れてしまうところがドキュメント指向恐るべし、といったところです。
ロックをしなくていい理由？それは、Aさん、あるいは、Bさんから口座残高の問い合わせがあったときに、その都度、銀行員さんが書類の山をもってきて、1枚1枚の収支を"手分けして"計算してくれるんですよ。CouchDBの場合は、前回計算した書類の山は覚えているので、Aさん/Bさんが長生きしてもほとんどの場合大丈夫です。
CouchDBってどんなシステムに向いているの？というのはもっともな疑問なんだけれど、「銀行の口座はロックしてコミットしなければならない」という先入観がある以上は、XXに向きます、だけの説明は聞いても絶対納得できないと思うのですよ。
