あるある ORM ドハマリ大辞典

DBMS の trigger

ORM の機能の trigger を多用していると、後続は DBMS 本体の trigger を使う事に躊躇します。使っちゃいけないというわけではないでしょうが、一つのクエリに対する副作用がある似たような機能を別レイヤーで使ってしまうと、トラブルが発生した時に ORM なのか DBMS に原因があるのかを切り分けるので混乱しそうです。

しまいにはお互いの副作用が混ざって酷いトラブルが起きてしまうかもしれないので「ああっ！ここで TRIGGER の定義できればラクなのに！！１」というシチュエーションでも泣く泣く諦めてしまいます。

Master Server に直接クエリを埋め込みにくい

ちょっとしたバッチ処理とかは shell script で書いてしまって、生 SQL を使ってデータを更新するとかやりたくなるケースは結構あると思います。

例えば ORM の insert trigger で「 url カラムに割り当てられた URL を HTTP GET して来てページタイトルを取得し title 絡むに埋め込む」的な定義がしてあるのを見落としてしまい、バッチ処理では url カラムにだけ値を入れていて後から「あれ？ページタイトルがない！」とか慌てるケースが出てくる可能性があります。この種のうっかりは注意してても発生してしまうので恐い所です。

道を外れると面倒

たとえば update 文の時は常に updated_at カラムを更新するという trigger が全テーブル共通処理として定義されていたとしましょう。まれに read_flg というカラムの更新した時だけは updated_at を更新したくないという要求が出てくる時があります。(まぁカラムを増やして対処するのが正しいのですが動いてるサイトにはそういう状況が出てくる物です。)
そういう時レアケースに対応しようとしだすと、別口でフラグを立てて bad code を書く事になったりとかアーキテクチャの変更を考えなければいけなくなったりとか大部面倒になります。

これだけ透過キャッシュ

もちろん、透過キャッシュすべきテーブルとしないテーブルとか別けて使う事になるんですけど、自分が作ったテーブルでもない限り意識的にならないとどのテーブルに透過キャッシュに入ってるか解らなくて、時たまデータが更新されてないと思ってビビる事がありますね。しかもエンジニアが絡まない view 側の変更をする人とかだともっと良くわからなくなるんじゃないかと思います。

too many memcach query

時たまキャッシュに入ってる事前提にして安心して

for my $id (@ids) {
    my $row = $orm->lookup($id);
}

とかしてて全部で2000クエリ位吐いてるページを見かけます。多分そのくらいのオーダーだと memcached でも問題でるんじゃねw
ORM でも油断しないように JOIN を使ってクエリ削減はしたいけど、透過キャッシュとかかましててそれが面倒い場合には最低でも select * from .. where ... で id list 引っ張って来た後に lookup_multi 的なくえりを叩いて DBMS memcached 双方に優しくなりたい物です。

れーすこんでぃしょんもんだい

一度 has_a したらキャッシュして二度同じクエリを投げないようにしてる時に、時たま

my $row1 = $orm->lookup(1);
my $row2 = $orm->lookup(1);
say $row2->has_a_table1->name;
$row2->has_a_table2->name('new name');
$row2->has_a_table2->update;
say $row2->has_a_table1->name; # あれれ new name になってないよ！

とかやっちゃう人が居ますが、その辺も注意がいりますね。