DBI->connectの第4引数の内容は設定ファイルに書かないほうが良い | おそらくはそれさえも平凡な日々
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
にひりずむ::しんぷる - DBI で KVS っぽいテーブルのデータをフラットなハッシュとして受け取りたい
例えば以下の様なテーブルがあったとして mysql> SELECT * FROM some_table; +-----------+----------+ | key | value | +-----------+----------+ | zigorou | moja | | antipop | idol | | bayashi | condom | | kazuho | BL | | ikebe | AKB48 | | clouder | yokohama | | satoshi | -- | +-----------+----------+ 以下のようにフラットなハッシュとして取得したいケースが合った場合。 { zigorou => 'moja', antipop => 'idol', bayashi => 'condom', ... } こんな感じでやればよい # $sql は適当
DBI->connect 時に使う鉄板オプションを教えて！ - blog.nomadscafe.jp
perlでデータベースを使う時に誰もが必ず使うDBI。その接続時に使うconnectメソッドの第4引数に設定しているオプションがサービスによりまちまちなんだけど、だれか鉄板設定を教えてください。 僕が使うのが、 my $dbh = DBI->connect($dsn, $user, $password, { AutoCommit => 1, PrintError => 0, RaiseError => 1, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); これ。 加えて、mysqlであれば mysql_enable_utf8 => 1 mysql_auto_reconnect => 0, SQLiteだと sqlite_unicode => 1 sqlite_use_immediate_transaction => 1 を追加し
DBIx::TransactionManager の目的と、その使用法について - tokuhirom's blog
おはようございます。 DBI では当たり前のように $dbh->do('BEGIN') と $dbh->do('COMMIT') をつかえばトランザクションがつかえるわけですが、なぜ DBIx::TransactionManager のようなものが必要になったのでしょうか。 それは勿論、DBI で直接 transaction をとりあつかうと問題が発生するケースが存在するからです。 トランザクションと RAII一番おおきいのは、トランザクションが中途半端な状態になってしまうことを阻止することです。たとえば、以下のようなケースでは、おかしなことになってしまいます。 my $dbh = DBI->connect(...); for (@stuff) { eval { $dbh->do("BEGIN"); $dbh->do(q{INSERT INTO t1 (v) VALUES (?)}, $_
DBIx::QueryLog でクエリの実行計画も丸見えにする！ - Articles Advent Calendar 2011 Dbix
好きって言葉は最高さーー！！！！kamipoです！！今日はAKB48の紅白対抗歌合戦があるので急いでいきたいと思います！！ DBIx::QueryLog で EXPLAIN の結果もロギングしたい xaicron さんの9日目のエントリ、[/articles/advent-calendar/2011/dbix/9:title=DBIx::QueryLog で DBI で実行された SQL を丸見えにする！]でおなじみの神モジュール DBIx::QueryLog 便利ですよね！？ でもEXPLAINの結果もロギングできたらもっと便利だと思いませんか？僕は思いました！！ そこで、EXPLAIN の結果もロギングできるパッチを取り込んでもらったので、新しいのが出たら使えるようになると思います！(いまはまだMySQLだけですが…) つかいかた とくにクエリに意味はないですが、こういうクエリを投げる
DBIx::QueryLog で DBI で実行された SQL を丸見えにする！ - Articles Advent Calendar 2011 Dbix
こんにちは、最近 PSP1000 の電池が一瞬で切れてしまってまともにゲームができない xaicron です。 さて、みなさんは DBI から吐かれた SQL をみたいなーと思うこともあるでしょう。 そんな時は、$ENV{DBI_TRACE} = 2 とかしてみると、ドバーッといっぱいデバッグログが出てきて、 その中に実際に発行された SQL がちょろっと出てたりするのでこいつを頑張ってパースすればいい感じですね！ っていうのはだいぶ面倒だったりしますね。あたりまえですね。 そこで、use するだけでとりあえず全部の発行された SQL を STDERR にはいてくれるモジュールを書きました。 その名も DBIx::QueryLog です。そのままですね。 つかいかた 使い方は至極簡単で、どっかで適当に use するだけです。ほかには何もいりません。 そうすると、以下のような感じで STDE
DBIx::Handlerで安心DB生活 - Articles Advent Calendar 2011 Dbix
こんにちは！nekokakです！ 今年はボクが作ってるDBIx::Handlerというものを紹介してみる。 DBIx::HandlerはDBIのラッパーでありDBのコネクション周りの管理に重点を置いたモジュールである。 ORMを使わずにDB周りの処理を行いたい場合はこのDBIx::Handlerを使うことをおすすめする。 自分でDBIのインスタンスを生成し利用する場合どこまで正しくコネクション管理をあなたはできますか？ そもそも親プロセスで接続したdbのインスタンスを子プロセス側でも利用することの問題を正確に把握していますか？ そこまで正しく細かく理解し自分で実装できたとしてもだ、新しいプロジェクトを作るたびにそのコードをコピペするのか？ そこでDBIx::Handlerの出番だ。 DBIx::Handlerはそのあたりの処理をすべて面倒みてくれる。 もうあなたは いつDBとの接続が着られ
DBI#cloneの取り扱い注意 - blog.nekokak.org
前の記事で、 clone使ったら接続きれてもて再接続できるよーといいましたが、 これは DBIを生で使う人が reconnectを実現するための機能ではありません reconnectするためだけにcloneつかうとかバカなことはやめましょう。 ORMを使わないケースで、処理中で接続が切れる可能性があり、自動で再接続をしたい場合はDBIx::Handlerを使いましょう。 DBIx::Handlerをつかわずに接続切れたらcloneとかいうコード書くと トランザクションに不整合が発生する可能性が生まれます。 なお、DBIx::Connectorではそのあたりの処理が中途半端でdatabase側から接続が切られた場合や ネットワーク的な問題で接続が切れた場合はよしなにやってくれないので やっぱりDBIx::Handlerをつかいましょう。 # DBIx::Connectorでは$dbh->FE
DBIとforkの関係 - heboi blog
実際ググれば正解はいっぱい出てくるしここに自分もコメントで書いてたりしていまさら書く必要もないかなと思ってたけど一応自分のブログでもまとめておくということで。 一般的な解 DBIx::ConnectorとかDBIx::Handler経由でかならず$dbhを取得してからDBIを使う。 もしくはfork-safeなORM(DBIx::Class, DBIx::Skinny, Teng)を使う。 DBIを直接使っている場合 一般的なコネクションを保持するクライアントと同様にDBIもforkした子供が親のコネクションをそのまま使うことはバグの原因になります。特にトランザクションの処理等で重大な問題が起こる可能性がある。 解決策は、 DBIのコネクションを親で作らないで、子供で独自に作る 親で作ってしまったコネクションを子供が安全にDESTROYし、再接続する のどちらかになります。ここで問題は2で
tokuhirom blog
Amon2::DBI からはじめるデータベースアプリケーション 〜 軽量フレームワークAmon２入門 (５) 〜 はい! というわけで3連休あけですね。 Ruby 会議にいったり、Android なんとかにいったり、リア充生活をおくったりと、各自たのしい3連休をすごされたことかとおもいます。 さて、連休あけの今日は、かるく Amon2::DBI について解説をしてきましょう。 Amon2::DBI は、DBI の薄いラッパーで「素の DBI だとちょっと不便だな」というところにピリリときいてくる山椒のような存在です(ちかくのチンマーハンは山椒がきいてなさすぎるので、もうちょいきいてるといいなとおもいます)。非常にうすいラッパーだし、コードベース自体も非常に簡潔なので、ひととおりよんでからつかうといいかとおもいます。 DBI には子クラスを設定できる機能があって、Amon2ではそれをつかって
Perlでシグナル処理（DBIを黙らせる編） - D-6 [相変わらず根無し]
Perlでシグナル処理（DBIを黙らせる編） 2011年4月27日 01:42 D | ブログ記事のURL | コメント(0) | トラックバック(0) なんかふと気づいたら最近以前書いたPerlでシグナル処理の記事にブクマがついていたので続き的な感じで書いてみた。 例えば 以下のように、ワーカーとかでずーーーーっとDBにクエリを投げてその結果を使って処理をする、というような処理を書くとする while ( $loop ) { my $sth = $dbh->prepare( .... ); $sth->execute(); while ( $sth->fetchrow_arrayref ) { .... } } 以前書いた%SIGを用いたPerlの普通のシグナル処理では、もしexecute()でブロックしていた場合など（例：Q4Mでqueue_waitしてる）ではいくらSIGINTとかを
生 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
libmysqlclientを使うプログラムはset namesをutf8であっても使ってはいけない | へぼい日記
mysql_enable_utf8 => 1 で DBIC::UTF8Columns 要らなくなるっぽいComments 上記の記事のブクマに set namesを直接実行しちゃうのはutf8であってもコンパイルオプションによっては問題起こるのでお勧めできない http://b.hatena.ne.jp/nihen/20090204#bookmark-11950629 ってことを書かせてもらったんだけど、この最後のset namesはutf8でも使っちゃダメという話を軽く説明します。 まずは、基本的なことはMySQL5開拓団 – 日本語処理の鉄則 / KLab株式会社を読んでください。mysqlの日本語処理についてのドキュメントとしては、私は今一番信頼できるドキュメントだと思っています。 さて、上記のページの< 図3：クライアント側文字コードの指定チャート>を、勝手ながらすべて引用させてい
DBIx::Inspector で DB の中をのぞきみる - Articles Advent Calendar 2010 Hacker
ベストスピーカー賞をもらった tokuhirom です。 1981忘年会でのみすぎて、二日酔いが大変ひどいです。 さて、今回は裏をかいて、DBIx::Inspector の話をかこうかおもいます。最近わたくしは、Web エンジニアの7つのはしかのうちの一つである O/R Mapper を書いてます。 これは、高速で、ミニマリスティックで、安定していて、DBI をリスペクトしていて、みたいな、そんなのをめざしてます。 O/R Mapper かく人って、O/R Mapper をかくときに必要なものとかを、まるっと同梱したがりがちなんですね。 そういうつくりにしてしまうと、別個なかんじの O/R Mapper をかこうとしたときに、つかいまわしがきかなくていっぱいコピペしなくちゃいけないです。 それかなしいよねってことで、みんなが共通につかえるパーツをちょっとずつかいてみようかな、とおもってます
How do you trace your query with DBI - tokuhirom's blog
DBIx::QueryLog とかつかわなくても Callbacks を駆使すれば結構いけるよ!っていう話になった。いいね。 use strict; use warnings; use DBI; my $dbh = DBI->connect('dbi:SQLite:','','', { RaiseError => 1, Callbacks => { ChildCallbacks => { execute => sub { my ($obj, @binds) = @_; my $stmt = $obj->{Database}->{Statement}; $stmt =~ s/\?/'$_'/ for @binds; print STDERR $stmt, "\n"; return; }, }, }, }); $dbh->do(q{create table job (func, time)})
にひりずむ::しんぷる - DBI で実際に発行されるクエリーを取得する DBIx::QueryLog を書いた
季節が変わって、早速風邪をひいています。 さて、もう秋を通り越して冬の様相を呈してきた昨今ではありますが、DBI では、普通はプレースホルダを使い my $stmt = 'SELECT * FROM user WHERE user_id = ?'; my @bind = ($user_id); $dbh->do($stmt, undef, @bind); とか書くと思います。 このときに、実際にバインドされた後の SQL をみたいなーって衝動に駆られると思いますが*1、どう頑張ってドキュメントを読んでもわかりませんね。 こういうときは仕方ないので、$stmt と @bind を両方ログに出してお茶を濁していました。 $self->log->_dump($stmt, @bind); # => SELECT * FROM user WHERE user_id = ?, [1234] でもこれっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
725640’s gists