生DBIの構成例
こんにちは、最近 Nintendo 3DS の電池が一瞬で切れてしまってまともにゲームができないと嘆いていたら「それ、HOME ボタン押してソフトをサスペンドすると電池減りにくくなりますよ」とスーパーハックを教えてもらった cho45 です。
DBI を生で使うときの罠はだいたいもう書いてあるし特に書くことがありませんし、DBIx 系は最近だと DBIx::TransactionManager 以外使ってないので、最近の僕の構成を紹介してお茶を濁します。
構成例
connect_cached を使わない
1リクエストごとに connect しなおすようにしています。1リクエスト内に関しては自力で dbh インスタンスをキャッシュするようにしています。
connect_cached はハマりがちで、DB サーバにコネクションを残しまくったりしたので、なんかもう面倒になってやめました。
SQL::NamedPlaceholder を使う
どこで SQL が構築されたかさえわかれば SQL ビルダー系を使うのはメリット (細かい条件の WHERE とかの条件を安全に書けるとか) があると思うのですが、現時点で簡単なクエリしか作らないので、SQL をほぼそのまま書けるようにしています。
SQL は DB からデータひいてくることに関する DSL なわけで、それに SQL::Abstract 的なラッパーをかぶせると、DSL に DSL を被せるみたいになってキモいのでできるだけやりたくないのです。
モデルで DB をひかない
モデルクラスで勝手にDBをひいたりしてしまうと、「DB をひいている」という意識が低下するので、絶対しないようにしていて、本当にただのデータとロジックの集合になるようにしています。
いわゆるリレーション的なものは、モデルの外でひいて、必要なデータだけをセットするようにしています。
DBIx::TransactionManager を使う
トランザクションをはるときは DBIx::TransactionManager を使っています。おまじないっぽい eval を書かなくてすむのでよいです。
まとめ
DBI 生で使うのはいろいろ面倒なことも多いので、個人的になんか作るなら Teng 使うのがいいと思います。