いまさっきcodereposにDBix::Skinnyというものをimportしました。 http://coderepos.org/share/browser/lang/perl/DBIx-Skinny 昨今のDBICブームで利用者は増えてきたんですが、いろいろ使うにあたって、 ここまでORマッパーでいろいろ(JOINしたり、キャッシュしたり)やるのはどうなんだとか、 うんたらかんたら考えたら自分で作ってしまえてのが動機でした。 DBICははっきり言ってどでかいライブラリなので一からソースを読むのがかなり大変です。 仕事で使ってる関係上、仕方なく見ることもありますが、キツい。 あと、DBICを使っているとJOINしたSQLがある意味簡単に発行できるので 重宝するのですが、ぶっちゃけどういうSQLが発行されているか全部ちゃんと見てる人って どれくらいいるのだろうと思ったり。 DBICによって
季節が変わって、早速風邪をひいています。 さて、もう秋を通り越して冬の様相を呈してきた昨今ではありますが、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] でもこれっ
SQL::Abstract を使い倒す - JPerl Advent Calendar 2009 Perl に関するちょっとした Tips をのっけてみるよ。ちゃんと続くかな? 今更、携帯小説にハマってる id:ZIGOROu です。モバゲーのオンライン3って小説が面白いですよ! 今日は SQL::Abstract を使い倒すと言うネタで行きます。 まず超基本編 簡単な SQL 文の生成から始めましょう。 use strict; use warnings; use Data::Dump qw(dump); use SQL::Abstract; my $s = SQL::Abstract->new; my ($stmt, @bind) = $s->select( "activity", # tables [qw/id title sender created_on/], # columns
2007-01-19 期間指定で、データを抽出したい時、当初 my $articles = $schema->resultset('Article')->search( { created_on => { '>' => "2006/01/01 00:00:00", }, created_on => { '<=' => "2006/01/05 23:59:59" }, }); でいけるかと思ったんだけど、ダメ。最後のものしか有効にならない。そりゃそうか。 my $articles = $schema->resultset('Article')->search( { created_on => { '>' => "2006/01/01 00:00:00", '<=' => "2006/01/05 23:59:59" }, }); とするか、もしくは my $articles = $schema
VERSION-0.05000での記述。http://search.cpan.org/~mstrout/DBIx-Class/ ドキュメントも当初に比べれば増えてきたし、そっち見たほうがよかばい。 まあ以下は簡単なまとめで。一通り使えるくらいは書きたい。 このサイトはWikiなので途中途中に色々追加したり修正したりしますからご注意を DBIx::Class::Schemaを使ってみる これからDBICではSchemaメインらしい。 使うテーブル作成SQL create table user ( id int(10) NOT NULL auto_increment, name varchar(256) NOT NULL, PRIMARY KEY (id) ) ENGINE = InnoDB;
格言「困ったら、Scalarりふぁれる」。 です。はい。 本日もDBICネタですが、DBICのRで困ったらスカラーリファレンスです。はい。 $self->model('User')->search( { 'me.created_on' => \'IS NULL', } )->first; created_onはDATETIME型とします。 こんな感じで実行すると、 SELECT me.created_on, me.rid, me.id FROM user me WHERE ( me.created_on IS NULL ) こんなSQLが実行されます。 さらに、 $self->model('User')->search( { 'me.created_on' => \' > NOW()', } )->first; こんな感じで実行すると SELECT me.created_on, me.ri
追記 2006/12/06 下記で IS NOT NULL を実現するのにスカラーリファレンスを使用していますが,IS NULL / IS NOT NULL を出すためには必ずしもスカラーリファレンスを利用する必要はありません。ということで訂正を入れようと思ったんですがちょっと長いので「フォローアップ記事」を書きました。 本題 typester さんに以前教えて頂いたんですが,似たようなことに今日遭遇したのでメモ。 WHERE field1 IS NOT NULL な検索をしようと思って, $resultset->search({ field1 => 'IS NOT NULL' });と書くと,内部的には SELECT ... WHERE field1 = ?と展開されて,プレースホルダに「IS NOT NULL」が渡されるので,バツ。 $resultset->search({ field
今日もCatalyst & DBIC のお話。テーブルにデータをINSERTするときに、そのレコードの作成日としてcreate_date みたいなカラムを用意する事は多いよね?で、だいたいそのカラムにはdefault にnow()とかsysdate() を設定する事が多いね。 でも、無精してdefault をセットしない事も沢山あるよね。その場合にはINSERT時、つまりDBICではcreate 時にnow() を突っ込みたくなる。でも、これが意外と簡単にはいかない。 DBICで本当に困ったら SCALAR REFERNCE を使えっつうことで、スカラーリファレンスで解決しました。 こんな感じ my $map = $c->model( 'DBIC::TranMatchmake' )->create({ user_id => $c->session->{user_id}, user_name
検索 検索結果のページ分け 問い合わせに対して大量の結果が返されることが予想される時は、DBIx::Classに対して結果セットをページ分け(一度に少しずつ取得)するよう要求することができます: my $rs = $schema->resultset('Artist')->search( undef, { page => 1, # 取得したいページ番号(デフォルトは1) rows => 10, # ページ毎の件数 }, ); return $rs->all(); # 1ページ目を全て取得する page属性は、検索において必ずしも指定する必要はありません: my $rs = $schema->resultset('Artist')->search( undef, { rows => 10, } ); return $rs->page(1); # 最初の10レコードを含むDBIx::Class
名前 始めに DBIx::Classの流儀 テーブルは結果ソースになる 全ては結果セットである 検索は"prepare"に似ている DBIx::Classを作成する 手動で作成する DBIx::Class::Schema::Loaderを使用する 接続する 基本的な使用法 行を追加・削除する オブジェクトを取得する こちらもご覧ください 原文へのリンク 翻訳者 名前 DBIx::Class::Manual::Intro - DBIx::Class入門 始めに さて、あなたはいいかげんSQLにうんざりしていて、データベース操作のためのネイティブPerlインターフェースが欲しいと思っていませんか?もしくは、しばらくの間Class::DBIを使っていて、これよりももっとよい方法がないかと考えていませんか?あなたは、正しい場所にたどり着いたのです。 DBIx::Classの流儀 ここでは、DBIx
名前 説明 結合とは何か 結合とリレーションシップを定義する 結合を使用する 複雑な結合など 複数のリレーションシップをまたぐ テーブルのエイリアス 自己結合を行う 原文へのリンク 翻訳者 名前 DBIx::Class::Manual::Joining - DBIx::Classでテーブルを結合するためのマニュアル 説明 このドキュメントは、DBIx::Classで結合を大々的に使用して(又は使用せずとも)、通常のSQLをDBIx::Classベースの問い合わせへ変換する際の助けになるでしょう。 結合とは何か ここまで来たものの、結合の何たるかが実際まだよく分からない、という場合は、ここの代わりにDBIx::Class::Manual::Introを読むのも良いかもしれません。結合の何たるかを心得ている場合は、このパートは読み飛ばしてください… ともあれ、ご説明しましょう。あなたが(非)常
前回の間違いを修正しました。 今回はCatalystでDBICを使う際、searchでjoinを実現する方法を説明します。 例アプリケーション名はMyApp。 ユーザー情報を格納しているUser というテーブルがあり、そこには都道府県がコードで格納されている。 都道府県はPref といテーブルにコード(pref_id)と都道府県名(pref_name)が1対1で対応している。 まず、model は下記のヘルパースクリプトで機械的に作っていますよ ね...?script/myapp_create.pl model DBIC DBIC DBI:mysql:mydb user passこれ(Catalyst::Model::DBIC)はあまり推奨されていないようですので、Catalyst::Model::DBIC::Schema を使うようにしましょう。script/myapp_create.p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く