なぜ Teng は良いものなのか - tokuhirom's blog
なぜ Teng は良いものなのか､を YAPC で再考させられたのでここにメモしておく｡ Teng は自社開発のウェブアプリケーションを作ってる人たちが作っていて､それがうちのニーズにあってるのでいいっていう話であって､どこでもすごい最高!! と主張したいわけではないです｡まあ､個人の感想ですね｡ ソースが読みやすい ソースがよくモジュール化されていて､読みやすい｡自身で書いている部分が多いという贔屓目を抜きにしても読みやすいんじゃないかなーと｡ 僕らのような自社開発のウェブ屋では､なにか無茶な要望を受けた時にささっと対応するということが求められるシーンが多いので､ソースの読みやすさというのはかなり重要なファクターとなっています｡ 複雑な SQL を発行できないように機能が制限されている SQL ビルダーを使って JOIN やサブクエリを駆使したウェブアプリケーションを開発してしまうと､運
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::DSN::Resolver::Cached をリリースしました - blog.nomadscafe.jp
YAPC::Asiaの前にDBIx::DSN::Resolverってのを書いてリリースしていますが、実際のWebアプリケーションで使うにはキャッシュやDNSRR対応などアプリケーション側でコードを書く必要があって面倒なので、簡単に使えるようラッパーとなるモジュールを書いてリリースしました。 https://metacpan.org/module/DBIx::DSN::Resolver::Cached DBIx::DSN::Resolver::Cached を使うことでDNSに掛かる負荷を押さえつつ簡単に負荷分散もできます。 use 5.10.0; use DBIx::DSN::Resolver::Cached; sub connect_db { state $r = DBIx::DSN::Resolver::Cached->new( ttl => 30, negative_ttl => 1
Teng vs DBIx::Skinnyベンチマーク 2012 - heboi blog
nekokakさんが以前TengとDBIx::Skinnyのベンチマークとってみたでとっていたのですが、１年半以上経っていてその後Tengはバージョンアップを重ねていますので、改めてとってみました。 ベンチマークスクリプトはnekokakさんのものをもとに少し改造してtestもつけたりしました。 結果はこちら。 はやくなってますね :)
O/R Mapper におけるページャーの実装について - tokuhirom's blog
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
DBIx::Skinnyを使った際のDBShardingの方法考察 - Hatena::Diary::Neko::kak 500 Internal Server Error
DBIx::SkinnyはDBIへの薄いラッパーなので ネイティブにDBShardingをサポートはしていません。 また、Shardingに限らずSlaveに勝手につないだりしてくれる便利機能もありません。 ただ、ShardingとかSlaveにつないだりはしたくなる事が有ると思うので、 サンプルコードを書いてみました。 サンプルコードはgithubにあります。 http://github.com/nekokak/p5-dbix-skinny-sample ただ、この記事を書いている時点ではgithubがぶっ壊れてるぽくcloneできません。:( 無料で使わせていただいているので文句は言えませんが。 サンプルコードでは DBIx::ShardManagerをつかってみました。 http://svn.coderepos.org/share/lang/perl/DBIx-ShardManage
簡易2WaySQL - blog.nekokak.org
2WaySQLというものがあるわけです。 2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation を参考にしてもらうとして、 超絶簡単に説明すると、実行可能なSQLを書いておいて（where句の値もデフォルト値を書いておくので実行可能となる） プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。 どんなSQLかというと SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)こういう感じ。 普通に実行可能ですよね。 これを、 my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1
データ分散とインデックス最適化のためのハッシュ関数の利用 - Articles Advent Calendar 2011 Hacker
はじめに こんにちは、piarra です。みなさん、意識は高まっていますか？私は上々です。 という書き出しをやめたくてやめられなかったのが心残りです。 昨年までは、Casual Trackで寄稿させていただいていましたが、今年はYAPCで話したこともあり、Hacker Trackに初挑戦させていただきます。得意のMD5暗算法とその習得法について解説したいと思っていたところですが、より日常に役立つ方がよいかと思い、MD5やその他のハッシュ関数の活用法について少し触れてみたいと思います。 データサンプル DBMSを考慮せず、以下のようなデータサンプルがあったと考えてみましょう。 +----+-----------------------+ | id | url | +----+-----------------------+ | 1 | http://www.google.com | | 2
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への第一歩 - DBIのサブクラスを作る - Articles Advent Calendar 2011 Dbix
注意書き ここで紹介しているオレオレDBIxモジュールの作成方法は、ある種呪いにも似た副作用を発生させる可能性があるので十分に検討した上で利用してください。 あわせて DBIx 名前空間にあるモジュールは用法、用量を守って正しくお使いください。 はじめに こんばんは、DBIx トラック2日目をやる myfinder です。 今回は DBIx::ナントカ の紹介ではなく、オレオレDBIxへの第一歩として DBI のサブクラスを作る方法について書きます。 はじめの一歩 「千里の道も一歩から」という言葉がありますが、オレオレDBIxもまずは一歩を踏み出さないと始まらないと思います。 ということで、下記が最小のオレオレDBIxです。 use strict; use version; our $VERSION = '0.03'; package DBIx::OreOre; use parent qw
ORMについて - blog.nekokak.org
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
DBIx::Handler
つくった DBIx::Connectorに無駄が多かったため自前実装 やること fork safe connection management scope base transaction management auto reconnect database simple query execution ざっくりこんなこと 使い方 use DBIx::Handler; my $handler = DBIx::Handler->new($dsn, $user, $pass, $opts); # この時点で接続可能なdbhを使える $handler->dbh->$some_dbi_method(); while (1) { # 長時間DBへの接続がおこなわれておらず # 接続が切れた場合も大丈夫 $handler->dbh->$some_dbi_method(); }
DBIとforkの関係 - heboi blog
実際ググれば正解はいっぱい出てくるしここに自分もコメントで書いてたりしていまさら書く必要もないかなと思ってたけど一応自分のブログでもまとめておくということで。 一般的な解 DBIx::ConnectorとかDBIx::Handler経由でかならず$dbhを取得してからDBIを使う。 もしくはfork-safeなORM(DBIx::Class, DBIx::Skinny, Teng)を使う。 DBIを直接使っている場合 一般的なコネクションを保持するクライアントと同様にDBIもforkした子供が親のコネクションをそのまま使うことはバグの原因になります。特にトランザクションの処理等で重大な問題が起こる可能性がある。 解決策は、 DBIのコネクションを親で作らないで、子供で独自に作る 親で作ってしまったコネクションを子供が安全にDESTROYし、再接続する のどちらかになります。ここで問題は2で
DBI#cloneというメソッド - blog.nekokak.org
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
DBIモジュールを使う時にNULLを入れる場合。 - 関打エアコン
Perlでプレースホルダの引数にNULLを入れるとか、 さんざんやってみたがうまくいかなくて悩んでたんよね。 以下の方法で解決できそう。 perl と ごはん: DBI モジュールで NULL をバインドする http://blog.bombdamage.com/archives/2004/12/dbi_null.html DBI モジュールでNULLをバインドするには以下のSQLを記述をすればよい。 WHERE (product_code = ? OR (? IS NULL AND product_code IS NULL)) なるほど。 プレースホルダの引数に何も値が入ってこなかった場合、 もしくはNULLの場合に、product_codeにNULLをセットする、 というわけね。 これ、簡単には思いつかないよ。。。(--;
にひりずむ::しんぷる - DBIx::QueryLog 更新
デフォは STDERR に出力しててたんですが、$DBIx::QueryLog::OUTPUT にファイルハンドルなら何でも設定できるようになりました。 が、今考えたら、Log::Minimal みたいな感じにしたほうがよかった！ 一応、DBIx::QueryLog->logger($logger) とかで logger 指定できるのでいいんですけど。 あと、color と compresscompact と useqq っていうオプションを追加しました。 それぞれ env DBIX_QUERYLOG_(COLOR|COMPRESSCOMPACT|USEQQ) とかでも設定できます。 compress は compact にかわりました 軽く例を上げると、useqq は # local $Data::Dumper::Useqq = 1; # local $Data::Dumper::Ter
第39回 DBIx::Skinny：DBIx::Classに不満を感じたら | gihyo.jp
DBIC以降の選択肢 今回はデータベース話の締めくくりとして、DBIx::Class以降に登場したいくつかの選択肢についてざっくりまとめておきます。これらはいずれも若く、DBICに比べてユーザ数も少ないためドキュメントなどの整備が遅れている部分もありますが、今回とりあげるものの多くは日本人がつくっているものですから、英語圏で開発が進められているものより疑問や要望は送りやすいはず。気になることがあったらぜひそれぞれの作者氏に伝えていただければと思います。 DBIx::Skinny nekokakこと小林篤氏のDBIx::Skinnyは、今回紹介するもののなかではもっとも実績豊富なものといってよいでしょう。開発の動機については氏のブログによくまとまっていますが、標準で用意されているCRUDメソッドを使うときだけでなく、速度を稼ぐために生のSQLを書いたときでもinflateなどの補助機能を使え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tokuhirom/teng-handbook
Perl DBI - dbi.perl.org