DBIとforkの関係 - heboi blog
実際ググれば正解はいっぱい出てくるしここに自分もコメントで書いてたりしていまさら書く必要もないかなと思ってたけど一応自分のブログでもまとめておくということで。 一般的な解 DBIx::ConnectorとかDBIx::Handler経由でかならず$dbhを取得してからDBIを使う。 もしくはfork-safeなORM(DBIx::Class, DBIx::Skinny, Teng)を使う。 DBIを直接使っている場合 一般的なコネクションを保持するクライアントと同様にDBIもforkした子供が親のコネクションをそのまま使うことはバグの原因になります。特にトランザクションの処理等で重大な問題が起こる可能性がある。 解決策は、 DBIのコネクションを親で作らないで、子供で独自に作る 親で作ってしまったコネクションを子供が安全にDESTROYし、再接続する のどちらかになります。ここで問題は2で
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
生 DBI ユーザーのための DBI Cookbook (6) - 日向夏特殊応援部隊
さて、今日は selectcol_arrayref です。昨日、会社のグルメな同僚に教えて貰いました。 ちょうど 生 DBI ユーザーのための DBI Cookbook (1) - Yet Another Hackadelic にて selectall_arrayref + Slice, selectall_hashref などの使い方を書きましたが、こちらもかなり便利。 CREATE TABLE `application` ( `id` int(10) unsigned NOT NULL, `title` varchar(32) CHARACTER SET sjis NOT NULL, `created_on` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', `updated_on` timestamp NOT NULL DEFAULT
dbicdump があるから使い捨てスクリプト書く必要はなかった - 理系学生日記
Perl で DBIC を使用して DB 系のプログラムを書くときは、スキーマクラスの作成のために、よく DBIC::Schema::Loader の make_schema_at を使った使い捨てスクリプトを書いていました。しかし、そもそもその必要はなかった。 DBIC::Schema::Loader には dbicdump というスクリプトが付属されていて、これを使えば DB からのスキーマの読み込み、およびスキーマクラスの作成を全て行ってくれる。 $ dbicdump -o dump_directory=./lib/ My::Schema 'dbi:SQLite:dbname=db/rank.db' $ find lib/My/Schema lib/My/Schema lib/My/Schema/Result lib/My/Schema/Result/Ranking.pm dbicd
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
