表題の通りですが、思うところがあってDBIx::Thinを削除しました。きっかけは、CPAN Ratingsのレビューです(以下引用)。
DBIx-Thin (0.05) **
It strikes me as odd how almost most of Japanese authors (of course, except honourable and admirable authors) don’t write why they have written their modules and the intention of the modules.
So is the author of this module.
The module is yet another ORM module but unfocused one. What the heck is different from DBIx::Skinny? The explanation is nowhere to be found, but there is just an enumeration of methods. And yet could anyone else use the module?
言われてみればその通りで、PODにコンセプトも書いてなければDBIx::Skinnyと違うところも良くわからないと。その辺に関してはモジュールのPODに書いておきましたが、それでもDBIx::Skinnyとあんまり変わらないし、現時点で自分以外の誰かが使っているとも思えないので、変な混乱を招かないようにCPANからは削除しました。んでgithubでは開発を継続していきます。
今年のYAPC(9月)からすき間時間を使って作っていたDBIx::Thinという、DBIx::Skinnyインスパイアなモジュールを昨日やっとリリースしました。作った動機は単に自己満足の追求と車輪の再発明による個人のスキルアップですが、前職で3年前ぐらいに自作したORMのコードを忘れないうちに改良して世に出したいなぁとずっと思っていたのです。SkinnyのAdvent Calendarが日々更新されているのを読み、途中で何度も「これSkinny使えばいいんじゃね?」って思って挫折しかけましたが、Skinnyも細かいところでは自分のポリシーと合わない部分があったりしたのと、とりあえず作ってしまったので世に出してみます。
特徴としては
- 生SQL派にやさしい
- Skinnyより書き方は冗長だと思うけど、コードを見て何をやっているかわかるようにした
- 依存モジュールが少ない(標準以外のものは3つ)
- Schemaクラスを生成するジェネレータが標準添付(ただしまだMySQL以外のDBに対応していない)
かなと思います。SQLはなんだかんだ言ってもまだWebエンジニアの共通言語だと思うので、ORMでゴリゴリJOINのコードを書くより生SQLの方がわかりやすい、と思っているので、生SQLなモジュールを作りました。
「Skinnyより書き方は冗長」というのは、例えばSkinnyだと
my $iterator = Your::Model->search(
'user',
{id => 1},
{order_by => 'id'}
);
と書きますが、2つ目の引数が何を表しているのかぱっと見わからないので、Thinの場合は
my $iterator = Your::Model->search(
'user',
where => {id => 1}, # これ
order_by => 'id',
);
と書くようにしています。もちろんSkinnyも学習すれば全然わかると思うので、細かいどうでもいいことかもしれませんが…
あとSkinnyと違う点は、
- SchemaクラスとレコードのRowクラスは分離されていますが、シンプルさを重視してあえて一緒のクラスにまとめているところ(Your::Model::UserみたいなクラスがSchema定義をしてさらにこれのインスタンスがRowオブジェクト)
- Schemaクラスの書き方がSkinnyはinflateやutf8がルールベースで全テーブルに適用されますが、こっちは基本的にテーブルの各カラムごとに書くようにさせてます
ところぐらいでしょうか。
最後に、Skinnyのコードはすごく綺麗で色々な部分を参考にさせてもらいました。作者のnekokakさん、どうもありがとうございました。
コメント