Otogiri-0.13 has been released
「ORMのような何か」であるOtogiriの新バージョン、0.13をリリースしました。以下、大きな変更点について説明していきます。
イテレータの追加
今までなかったのが不思議なのですが、ようやくイテレータを追加しました。
従来ですと、いくつかのレコードをselectするには、
my $db = Otogiri->new(...);
my @rows = $db->select('book' => {...});
のように、配列で受け取る以外の方法が提供されていませんでしたが、0.13以降は
my $db = Otogiri->new(...);
my $iter = $db->select('book' => {...});
while (my $row = $iter->next) {
...
}
という感じでイテレータを通してレコードを取得することが可能となります。
イテレータはDBIx::Otogiri::Iteratorというクラスのオブジェクトで、nextメソッドくらいしか提供していません。
そしてnextメソッドは実質上、DBD::st->fetchrow_hashref
とほぼ一緒ですので、レコードがやたら多いケースでもメモリを食いつぶさずに済むようになります。
SQL::Makerのstrictモードへの対応
OtogiriのコードはSQL::Makerとかなり密結合になっているのですが、そのSQL::Makerに1.16でstrictモードというものが実装されました。
strictモードが実装されるまでの経緯ですとか説明は、下記エントリおよびドキュメンテーションを参照いただきたいと思います。
不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) — Mobage Developers Blog
SQL::QueryMaker - helper functions for SQL query generation - metacpan.org
非常に掻い摘んだ説明をするならば、SQL::MakerのWhere指定箇所にJSONをデコードしただけのHashリファレンスを何のバリデーションもなしに突っ込むと、SQL Injectionの危険性を生じますよ、といったところでしょうか。
ちなみにこのような問題は別にSQL::Makerに限らないと思いまして、結局のところユーザ入力を信頼しきった状況というのが危険性を生むということだと思います。
さて、そんなわけでOtogiri側でも何かしらの対応が必要だろうということになりまして、おおまかに以下の方針で対応致しました。
デフォルトでSQL::Makerのstrictモードを有効にするが、
Otogiri->new(strict => 0, ...);
とすることで無効化することもできる(つまり従来どおりの使い方ができる)。use Otogiri;
をした時点で、SQL::QueryMakerが提供するDSLをexportする。
2については以下のように書けるようになります。
### 従来(0.13以降では、デフォルトでこのような書き方ができなくなる)
use Otogiri;
my $db = Otogiri->new(connect_info => [...]);
my @rows = $db->select('book' => {price => {'<=' => 1000}});
### 新しい書き方
use Otogiri;
my $db = Otogiri->new(connect_info => [...]);
my @rows = $db->select('book' => sql_ge('price' => 1000));
これは賛否の分かれる内容かと思っておりますが、現状の開発メンバーの使い方にはこの位の対応がちょうど良い、という結論から、このようにした次第です。
最後に
YAPC::Asia tokyo 2014 では、tsucchiさんと共同でOtogiriについての発表および対談ができるかもしれません(できないかもしれません)。
このエントリを執筆している時点では選考中ですが、もし受かったら、短い時間の中ではありますが、この辺の話にも少し触れておきたいと考えております。
聞きたいと思った方、ぜひ今からでも構いませんので、いいね!してもらえるとうれしいです。