Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
環境 ubuntu lampp perl DBI DBD::mysql perlで DBI->connect()しようとしたら failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at insert.pl line 11 というようなエラーが発生して軽くつまった。 多くの人が 「DBIでCan't connect to local MySQL server through socket '/tmp/mysql.sock'」 http://diary.lampetty.net/20060926.html にて解決してるが、自分はダメだった。 my.cnfを書き直しても、 perlの出力するエラーは依然として failed: Can't connect to l
主に自分用メモ。例えば以下のようなコードからDBIハンドルを取得してるとする use strict; use DBI; sub get_dbh { DBI->connect_cached(....); } sub foo { my $dbh = get_dbh(); $dbh->do(...); } sub bar { my $dbh = get_dbh(); $dbh->do(...); } foo(); bar(); .... で、まぁSET NAMES utf8を自動的に発行したいなーと思ったので、get_dbhに手を入れる sub get_dbh { my $dbh = DBI->connect_cached(...); $dbh->do("SET NAMES 'utf8'"); return $dbh; } そうするとget_dbh()内で DBIハンドル自体はconnect_c
先日DBIを使っていて、謎な挙動に遭遇したので書いてみる。LIMIT, OFFSET句でプレースホルダーを用いた時に起こった。DBI + DBD::mysqlを使っていた。 DBI: 1.616 DBD::mysql: 4.022 LIMITとOFFSETを両方にプレースホルダーを使う LIMITとOFFSETを両方を?にするのはうまくいく。 $res = $dbh->prepare_cached(q[ SELECT * FROM user WHERE name = ? LIMIT ? OFFSET ? ])->execute('shiba_yu36', 1, 1); LIMITのみプレースホルダー LIMITのみ?でもうまくいく。 $res = $dbh->prepare_cached(q[ SELECT * FROM user WHERE name = ? LIMIT ? OFFSET
DBIx::QueryLogを使ってちゃんとSQLが流れているかテストする - $shibayu36->blog;で、流れているSQLをテストしたいと言う話をしたら、tokuhiromさんにDBIx::Tracerを使えばもう少しシンプルにかけると言われたので、やってみました。 (再掲) テストしたい状況 package My::DBI; use strict; use warnings; use DBI; sub connect { my ($dsn, $username, $password) = @_; my $dbh = DBI->connect($dsn, $username, $password, { Callbacks => { connected => sub { my $dbh = shift; $dbh->do("SET NAMES utf8") or warn $db
最近DBへの接続をリクエスト単位ではなくリクエストを処理するプロセス単位(Starmanのworkerプロセス単位)でキャッシュしたいということがあって、DBIのconnect_cachedを使うことになった。Scope::Container::DBIでももしかしたら出来るのかもしれないけど、とりあえずconnect_cachedで実装した。そこでいろいろはまったのでメモ。 connect_cachedについて perldocに connect_cached is like "connect", except that the database handle returned is also stored in a hash associated with the given parameters. If another call is made to connect_cached wit
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 の目的と、その使用法について おはようございます。 DBI では当たり前のように $dbh->do('BEGIN') と $dbh->do('COMMIT') をつかえばトランザクションがつかえるわけですが、なぜ DBIx::TransactionManager のようなものが必要になったのでしょうか。 それは勿論、DBI で直接 transaction をとりあつかうと問題が発生するケースが存在するからです。 トランザクションと RAII 一番おおきいのは、トランザクションが中途半端な状態になってしまうことを阻止することです。たとえば、以下のようなケースでは、おかしなことになってしまいます。 my $dbh = DBI->connect(...); for (@stuff) { eval { $dbh->do("BEGIN"); $dbh
DB操作ツール Emacs DBI を作ってみた - 技術日記＠kiwanami このツールの目的は、クロスプラットフォームで便利なDB操作環境を実現することです。 pgAdmin や MySQL Query Browser のようなGUIの良さをCUIで実現してみようとしてみました。すなわち、ぼくのかんがえたさいきょうのDBツールです。ちなみに、このツールにとってEmacsはただの実行環境です。Emacs使わない人でも使うと便利だと思います。 http://d.hatena.ne.jp/kiwanami/20120305/1330939440 VimもーVimもー！ って事で作りました。 mattn/vdbi-vim - GitHub Database client for Vim https://github.com/mattn/vdbi-vim Emacs版はepcというRPCプロト
去年からほそぼそと作ってきた、EmacsからDBを操作できるツール Emacs DBI を紹介します。 Emacs DBI の簡単な紹介 このツールの目的は、クロスプラットフォームで便利なDB操作環境を実現することです。 pgAdmin や MySQL Query Browser のようなGUIの良さをCUIで実現してみようとしてみました。すなわち、ぼくのかんがえたさいきょうのDBツールです。ちなみに、このツールにとってEmacsはただの実行環境です。Emacs使わない人でも使うと便利だと思います。 データベース画面 e2wmで3ペインの画面 機能概要 以下のような機能があります。 EmacsとDB接続可能なPerlが動けばターミナルでも何処でも動く DB定義、テーブル定義がすぐ見れる auto-complete によるSQL補完 接続先DBにからキーワード、型名、テーブル名、カラム名など
師走にも関わらず風邪を引いてしましました。こんばんは、zigorou です。 今日は DBI のお供になりそうな拙作モジュールたちをご紹介します。 Data::RuledFactory p5-data-ruledfactory で開発中のモジュールです。 主要機能は大体出来てるんですが、後はテストを充実させて pod をきちんと書いたらリリースしようかなとか思ってる所です。 とはいえ現時点でもやりたいなと思っている事は既に出来ます。 論より証拠と言う事で、examples フォルダにある 001_define_rules.pl についてちょっと解説。 #!/usr/bin/env perl use strict; use warnings; use FindBin; use lib "$FindBin::Bin/../lib"; use DateTime; use Data::RuledF
大規模なサイトでは、ORMではSQLレベルのチューニングがしにくいので(Class::DBIで苦労してる)、SQLを直接書くことが多いと思います。その際SQLをいろいろなモジュールに書いてしまうと、あとからALTERやパーティショニングしようとした時に悲劇となります。できるだけ1つのテーブル・データベースのSQLは１つのモジュールにおさめておく事がおすすめです。 DBIx::Sunnyはそのようなモジュールを書く時に使えそうなライブラリで、SQLを管理すると共にクエリ実行時に渡された値のバリデーションもできる様になっています。まだまだ実験中ですが、githubにソースコードあります。 使い方はこんな感じ。まずSQLを書くクラスをDBIx::Sunnyを継承して作ります。query、select_one、select_row、select_allってのがSQLを管理する用の暮らすメソッドとし
前の記事で、 clone使ったら接続きれてもて再接続できるよーといいましたが、 これは DBIを生で使う人が reconnectを実現するための機能ではありません reconnectするためだけにcloneつかうとかバカなことはやめましょう。 ORMを使わないケースで、処理中で接続が切れる可能性があり、自動で再接続をしたい場合はDBIx::Handlerを使いましょう。 DBIx::Handlerをつかわずに接続切れたらcloneとかいうコード書くと トランザクションに不整合が発生する可能性が生まれます。 なお、DBIx::Connectorではそのあたりの処理が中途半端でdatabase側から接続が切られた場合や ネットワーク的な問題で接続が切れた場合はよしなにやってくれないので やっぱりDBIx::Handlerをつかいましょう。 # DBIx::Connectorでは$dbh->FE
id:nekokak さんが開発されている、Teng で CRUD を一通りやってみました。 僕自身、DBIx::Class を以前使っていたんですが、あまりにも機能が富豪的すぎて使うのをやめてしまいました。それからは生 DBI を使っていたんですが、開発効率を考えたときに、ORM は使うべきだと再度考えるようになり、軽量な ORM、Teng に注目している所です。 準備 テスト用のテーブル +------------+-----------+------+-----+---------------------+-----------------------------+ | Field | Type | Null | Key | Default | Extra | +------------+-----------+------+-----+---------------------+-
http://search.cpan.org/dist/DBI/DBI.pm#clone DBIにcloneメソッドがあることを@nihenさんがみつけました。 #いやーDBIのドキュメントは良く読むと便利メソッドが一杯ありますね TengとかSkinnyではconnect_infoを受け取るだけでなく、 $dbhを受け取って利用する仕組みも提供しているのですが、 そこで一番問題になっていたのはdbへの接続がブチギレた場合のreconnectの問題でした。 connect_infoがある場合は接続情報を自分で持っており、簡単に再接続できるんですが $dbhしかない場合はいままでできないとおもっていました。 DBI的にも接続時につかったpasswordを取るインタフェースがなかった。 なので$dbhを渡された場合は自動reconnectは行わずにエラーで死亡にするようになってたんですが、 D
PerlのDBIモジュールのcloneメソッドがいいらしい 『DBIとforkの関係』とか『DBI#cloneというメソッド』とかで、取り挙げられているDBIのcloneメソッドを実感するためのサンプルコード。 #!/usr/bin/env perl use strict; use warnings; use DBI; my $dbh = DBI->connect('dbi:mysql:;', 'test', 'test'); warn $dbh->do('show processlist'); $dbh->disconnect; warn $dbh->do('show processlist'); $dbh = $dbh->clone; warn $dbh->do('show processlist'); コネクションの再接続がなんとお手軽! コネクションの維持に関しては『Scope::
実際ググれば正解はいっぱい出てくるしここに自分もコメントで書いてたりしていまさら書く必要もないかなと思ってたけど一応自分のブログでもまとめておくということで。 一般的な解 DBIx::ConnectorとかDBIx::Handler経由でかならず$dbhを取得してからDBIを使う。 もしくはfork-safeなORM(DBIx::Class, DBIx::Skinny, Teng)を使う。 DBIを直接使っている場合 一般的なコネクションを保持するクライアントと同様にDBIもforkした子供が親のコネクションをそのまま使うことはバグの原因になります。特にトランザクションの処理等で重大な問題が起こる可能性がある。 解決策は、 DBIのコネクションを親で作らないで、子供で独自に作る 親で作ってしまったコネクションを子供が安全にDESTROYし、再接続する のどちらかになります。ここで問題は2で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く