はじめに

Ruby on Railsの2年半ぶりのメジャーバージョンアップである3.0の正式リリースがいよいよ間近に迫ってきました。

Rails 3は，アプリケーション・レベルではRails 2.3との互換性をなるべく保ちながらも，メジャーバージョンアップだけあってフレームワーク自体は隅々にまで徹底的なリファクタリングが施されて更なる洗練を遂げています。結果として，Rails 3では融通の効かないフルスタック構造を捨ててすっきりとしたモジュール独立性が実現されているのですが，この際に，Merbとの合併の影響もあってか，いくつかの新たな外部ライブラリに依存する形になっているのも興味深いところです。

そこで本稿では，あえてRails 3そのものではなく，このRails 3の大改造の舞台裏を支える裏方さんにスポットライトを当ててみたいと思います。

Arelによってパラダイムが大きく変わったActiveRecord 3

今回のRailsのメジャーバージョンアップの中でも特にドラスティックに変身を遂げたのが，データベース層を司る，ご存知ActiveRecordです。大げさに言えば，ActiveRecord 3では，従来のO/Rマッパーとは一線を画した，O/Rマッピングの概念を一段高いステージに押し上げるような，全く新しい世界観が表現されています。では，新しいActiveRecordでは，一体どのような新機能が，一体どのようにして実現されているのでしょうか？

従来のActiveRecordでは，（⁠世の中のほとんど全てのO/Rマッパーがそうであるように）文字列ベースで組み立てたSQLをfind()メソッドの呼び出しでドカッとまとめてDBに投げていたのですが，ActiveRecord 3では，RubyのDSLで書かれた条件を最終的にSQLの文字列に変換する処理は「Arel」という中間ライブラリで行われるようになっています。

どうやら，ActiveRecord 3の新しいクエリインターフェイスの鍵は，このArelが握っているようです。そこで，このArelというライブラリについて，少々深く掘り下げて調べてみることにしましょう。

すべてが「named_scope」!?

もともとこのArelというライブラリは，ActiveRecordのnamed_scope機能の作者である Nick Kallen氏（※1）が着想して作り始めたものです。この時の設計の意図については，彼自身のブログで以下のように語られています。

After I wrote “named_scope” I immediately asked myself “but what if every query was a named_scope? What if named_scope were the rule and not the exception?⁠”.

Nick Kallen氏のブログ「Magic Scaling Sprinkles」より

※1

現在はTwitter, Inc.に勤務。昨年リリースされたTwitterのLists機能のリーダーを務めたことでも有名。

Nickは，named_scopeをさらに汎用化させて関係代数における「関係（＝Relation）⁠」という概念をそのままオブジェクト化することによって，すべてのクエリをこの「関係」の「関係」で表した純粋で美しい世界が構築できるのではないかと考えたのです。この「関係」オブジェクトは，数学的には「クロージャ」であり，実装のアイデアは関数型言語に強くインスパイアされたものでした。

しかし，ActiveRecord全体をnamed_scopeっぽいものに変えるためには，ActiveRecordの根幹からガラッと作り替える大手術を行う必要があったため，いきなり複雑に肥大化したActiveRecordの手術に挑むよりは，まずは特定のO/Rマッパーに依存しないような汎用的なクエリ言語の設計から始めた方が良いのではないか，という判断に至りました。こうして作り始められたのが汎用オブジェクト指向関係代数クエリ言語「Arel」です。その後Nickがなんとわずか半年程度でArelをざっくりと作り終えると，このNickの試みはBrian Helmkamp, Emilio Tagua, Pratik Naikといった協力者たちによってActiveRecordへと組み込まれ，僕らのもとへと届けられることになりました。

のちほどActiveRecord 3で実際にクエリっぽいものを動的に組み立てて最後に遅延評価で実行させるコードをご紹介しますが，これは，「⁠すべてがscope」というビジョンに基づいて再設計が行われ，それが本当に実現されてしまったからこそ可能になっているわけです。

Arelについて

Arelとは，「⁠Relational Algebra」または「Active Relation」の略で，その名前から想像がつくとおり，ActiveRecordから派生した，「⁠関係代数」をRubyのオブジェクトで取り扱うためのライブラリです。

ドキュメントによれば，Arelは，

1. 面倒なSQLの生成を簡単にしてくれて，
2. さまざまなデータベースシステムに対応している，

「フレームワークのフレームワーク」を目指して作られています。

つまり，Arelを使えば，DBの互換性やSQL文字列の生成などに惑わされることなく，大事な設計やモデリングに注力してO/Rマッピング処理を実装することができるようになっています。

この仕組みは，WEB層でいうなら，ちょうどRackと同じ位置づけに当たります。RackがWebサーバーとWebアプリケーションの間を仲介してくれているのと同様に，ArelはデータベースとO/Rマッパーの間のごちゃごちゃとした部分を抽象化してすっきり整理してくれています。

また，「⁠さまざまなデータベースシステムに対応」というのは，単に複数のRDBMS製品の方言を吸収，というだけにとどまらず，SQLを使わないデータベース，インメモリのキャッシュ的なもの，さらにはYAML等のファイルへの永続化までを考慮して設計されています。ひと昔前までは，「⁠データベース操作」と言えば「リレーショナル・データベース・システム」に対して「SQL」という規格化された問い合わせ言語を用いて実装されることが多かったのですが，最近は「Key Value Store」⁠，「⁠クラウド」⁠，はたまた「NoSQL」といった形で，永続化や問い合わせの手法がどんどん多様化してきています。バックエンドの多様性を吸収して抽象化してくれることによってアプリケーションコードの汎用性を高めてくれるArelという存在は，まさにこんな時代の流れを的確に捉えたライブラリと言えるでしょう。

作者について

なお，Arelの作者であるNick Kallen氏は，QCon Tokyo 2010というイベントで来日を果たしており，筆者もArelについて直接質問をぶつける機会があったのですが，意外なことに，本人はArel自体の開発から手を引くと同時に既にArelというプロダクト自体に対してもさほど興味は残っていないようでした。本人も認めているとおり，彼はオープンソース活動を通じて自身の素晴らしいアイデアを世界にぶちまけることにやりがいを感じているのですが，その後のメンテナンスやら細かい作り込みにはそれほど熱心になれないようです(ある意味Rubyistらしいとは言えるかもしれませんね)。いずれにしろ，彼のような天才の仕事が，本人の手を離れてもコミュニティによって引き継がれて人類の共有財産になっていっている，というあたりは，オープンソースの世界の懐の広さを感じさせる現象ではないでしょうか。

その後も彼はまた全く別の分野で新たなプロダクトを作り始めているとのことなので，今後とも彼の活躍には期待したいところです。