Sequelと紛らわしい名前のSqueelは、ActiveRecord (Arel) を拡張して、よりベタ書きのSQLを減らそう、という試み。
Arelは "=", "IN", "BETWEEN" まではいいように抽象化しているけど、たとえば "LIKE" や ">=" といった演算はSQLをベタ書きしてプレースホルダを使わないといけなくなる。これは非常にイケていないな、と思っていたのだけど、やっぱりそう感じる人が他にもいたみたい。
Symbol#>= とかを定義したり、whereがブロックをとれるようになったりして、SQLのベタ書きがほとんど抑えられている。
次期DataMapperで使われる予定の汎用的なProperty APIライブラリ。型やデフォルト値などを持つプロパティをPORO (Plain Old Ruby Objects) に定義する汎用的なライブラリを目指している。
バックエンド (データベース) に依存しないので、PerlでいうMooseとかみたいなかんじで使えるのかな?
これも次期DataMapperで使われる予定のQuery Objectを提供するライブラリ。ActiveRecord (>= 3.0.0) で言うArelに対応するもの、というとわかりやすそう。ただし、バックエンドをRDBに限らない、つまり生成するQueryがSQLに限らない、というところを目指しているらしい。
READMEでは、MongoDBとCouchDBなどのNoSQLエンジンにも対応したい、と書いてある。
DataMapperの次のメジャーリリースではActiveRecordが3.0系で大きく変わったように、よりプラガブルでDataMapperパターン (ややこしい) に近づけるみたい。 (cf. solnic.eu: Ruby DataMapper Status)
Symbol#>= とか実装したくなる気持ちはわからんでもないけど, O/R マッパに求めるのってそういうことなんだろうか. 結局 SQL の呪縛から逃れられていないように感じる.
はてなブックマーク - taketyan のブックマーク
O/R Mapperは現状でオブジェクトと関係モデルのインピーダンスをマッチさせる役目とアプリケーション・コードにおけるクエリとバックエンドにおけるクエリのインピーダンスをマッチさせる役目があります。
後者についてO/R Mapperがそこまで責任を持つべきなのかという疑問はその通りで、次期DataMapperではクエリ・オブジェクトの生成をVeritasに外注するようです。
一方で、SqueelはARの拡張というよりクエリ・オブジェクトを組み立てるArelの拡張なので、O/R Mapper (AR) の責任を拡大させるものではないとおもいます。
