rails の「rake db:migrate」と似たような事を、Catalyst でもできないか?と思い、いろいろ調べてみた。 http://search.cpan.org/~bricas/DBIx-Class-0.07003/lib/DBIx/Class/Manual/Cookbook.pod#Easy_migration_from_class-based_to_schema-based_setup http://search.cpan.org/~bricas/DBIx-Class-0.07003/lib/DBIx/Class/Manual/Cookbook.pod#Schema_versioning SQL::Translator を使うのか・・・なるほど。 今は時間がないので、後で使い方をまとめよう。
http://www.ornithopter.jp/archives/2006/11/dbixclassdbic_d_1.html ケースによってはもっとスマートに扱えます。 こんな感じのデータがあったとします。 > select * from item; +----+------------+------+-------+---------------------+---------------------+ | id | rid | name | price | created_on | timestamp | +----+------------+------+-------+---------------------+---------------------+ | 1 | tkVjn4E2cQ | pen | 500 | 2007-02-17 13:55:06 | 2007-02
この組み合わせでSegumentFaultが出てしまう問題があったのですが、起こらなくなった... アパッチに組み込んでいたPHPを取り除くと解決した。 なんじゃそれ。 ようわからんが、勘弁してほしい。
Loaderを使うと各スキーマは定義しなくてもLoaderが自動にやってくれるのですが、 スキーマをちょーっと拡張したい時とかは軽く工夫します。 例えば、 +------------+------------------+------+-----+---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+------------------+------+-----+---------------------+----------------+ | id | int(10) unsigned | | PRI | NULL | auto_increment | | rid | varchar(10) | | UNI | | | | name_sei
とかいうのがDBICのCoreに入りました。 使い方は簡単?で use DBIx::Class::ResultClass::HashRefInflator; my $rs = $self->model('Blog'); $rs->result_class('DBIx::Class::ResultClass::HashRefInflator'); my $member = $rs->single({rid => 'HXOK7cI4DA'}); warn Dumper $member; こんな感じでresult_classに設定してやると 結果として $VAR1 = { 'timestamp' => '2007-01-18 17:03:06', 'member_id' => '15', 'created_on' => '2007-01-18 17:03:06', 'id' => '34', '
http://d.hatena.ne.jp/tokuhirom/20070126/1169812586 なんとなくDBICのにしてみた。 package DBIx::Class::Lock::MySQL; use strict; use warnings; use base 'DBIx::Class'; use Carp::Clan qw/^DBIx::Class/; sub get_lock { my ($self, $lock_id, $timeout) = @_; $self->{__MYSQL__LOCK__ID} = $lock_id; my $dbh = $self->storage->dbh; my $sth = $dbh->prepare('SELECT GET_LOCK(?,?)'); $sth->execute($self->{__MYSQL__LOCK__ID}, $
久々にCatalystアプリをApache2/worker+ModPerl2な環境で動かしてみたところ、 DBIx::Class::ResultSet::find(): no sth generated via sql (DBD::mysql::db STORE failed: handle 2 is owned by thread 926fb18 not current thread 9bf0448 (handles can't be shared between threads and your driver may need a CLONE method added) at /usr/lib/perl5/5.8/lib/DBIx/Class/Storage/DBI.pm line 524.という例外が発生するようになってしまいました。 DBIC周りの変更と言えば、DBIx::Clas
ここまでやってそういやjoinなんてのあったよね、と思い出してなにが違うんだろうと思ってやってみる。前のエントリのコードのprefetchをjoinに置き換えて比較。 join SELECT me.id, me.genre_name, me.place_name FROM master me JOIN genre genre_name ON ( genre_name.genre_name = me.genre_name ) JOIN place place_name ON ( place_name. place_name = me.place_name ) JOIN place_ref place_name_2 ON ( place_name_2.place_ref_name = place_name.place_name ): SELECT me.genre_name FROM genr
あけましておめでとうございます。ちょっと遅いかもしれませんが。 今年もバリバリPerlっていきたいです。 というわけでDBIC。 Catalystアプリで作ってたんですけどよく使い方がわからないのでDBIC単体でいじくり倒そうかと。 まずはテーブル。 CREATE TABLE genre ( genre_name VARCHAR(8) NOT NULL PRIMARY KEY ); CREATE TABLE place ( place_name VARCHAR(8) NOT NULL PRIMARY KEY ); CREATE TABLE master ( id INTEGER(5) NOT NULL PRIMARY KEY AUTO_INCREMENT, genre_name VARCHAR(8) NOT NULL, place_name VARCHAR(8) NOT NULL, FOR
こういうふうにメソッドはやしたいなら $hoge->('Artist')->hoge; こうすれば良かったのね。 package Hoge::Schema::Artist; use base qw/DBIx::Class/; __PACKAGE__->load_components(qw/ResultSetManager PK::Auto Core/); sub hoge : ResultSet { my $self = shift; } 下記サイトにお世話になりました。 あざっす。 http://blog.hide-k.net/archives/2006/03/dbixclassresult.php http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSetManager.pm
MySQLの関数を検索条件にぶち込んでほげほげしたい場合 $rs->search({'me.created_on' => {'>'=> \"NOW() - INTERVAL $span DAY"}); とか書くと、$spanがSQLインジェクションになりかねないの。 そういう場合はsearch_literal使うよろし。 $rs->search_literal('me.created_on >= NOW() - INTERVAL ? DAY', $span); こんなSQLで安全無敵 Executing : SELECT me.id, me.rid, me.name, me.created_on, me.timestamp FROM member me WHERE ( me.created_on >= NOW() - INTERVAL ? DAY ) : '1' まあINTERVAL使わな
InflateColumnを使っているときに問題があったため、修正版を新しいエントリに起こしました。 修正版:DBIx::Class + Catalyst::View::JSON(2) - ヒルズで働く@robarioの技ログ 昔書いたメモが出てきたので転載。 DBIC::ResultSet#findやDBIC::ResultSet#searchしたものをそのままJSONにしたいじゃないですか。 でもCatalyst::View::JSONにそのまま渡すとCatalystが落ちるんですよ。 なので適当に展開してくれるサブルーチンを作って使っています。 Catalyst::View::JSON以外でも使うので、アプリケーションクラスに置いています。 ### lib/MyApp.pm sub expand_dbic { my ( $c, $obj ) = @_; if ( !Scalar::U
http://d.hatena.ne.jp/hi-rocks/20061228/1167291723 結局、ResultSetクラスにメソッド生やしちゃうと、全部のSchema(テーブル)でそのメソッドが共有されちゃう その通りです。 こちらについては、findのように共通メソッドとして使うものだけを考えています。 例のretrieve_ridはどのスキーマでも使いたいメソッドになるので。 まあ、例が悪かったりもしますが。 MoFedge::Data::DBIC::ResultSetRegisterをもっと作りこめば このスキーマからしか実行できないぜ!とかもできますが、 EXPERIMENTAL!! です。オイラもつかってません>< ちなみにDBICでは、実はスキーマ毎のResultSetの拡張はあんまり必要ないかなとか思ってます。 CDBIの場合はset_sqlしたりなんやかんや動的に
Chained Searches: The Beauty of DBIx::Class And Catalyst DBIx::Class and Catalyst have made my life much easier since I adopted them. I originally began my $work project with Class::DBI. The transition took some work but I’ve been happy as a moose in a brothel ever since. Aside from the occasional hairy query I don’t think I push the limits of either Cat or dbic very often. There is one feature, h
普段からLoader使っている人には目新しい話題はない予定。 思い出すことから始めてるので。 load_from_connectionがdeprecatedになってた。 バージョン0.04000では削除されるらしいので使わないようにすべし。 ってことで、 package TestDBIC::SchemaL; use strict; use warnings; use base 'DBIx::Class::Schema::Loader'; __PACKAGE__->load_from_connection( dsn => 'dbi:mysql:test_dbic', user => 'test', password => 'testtest', relationships => 0, debug => 1, ); 1; こうではなく、 package TestDBIC::SchemaL; u
DBIx::Class::SchemaAccesserなるものを作りました。 ラボで公開ちう。 http://code.mfac.jp/trac/browser/CPAN/nekokak/DBIx-Class-SchemaAccesser/ Catalystとかのフレームワークを使っている場合は DBICのオブジェクトを毎回作るのはフレームワークのプラグインとかが 簡単&ほぼ勝手にやってくれるからいいのですが、 コマンドラインのツールとかフレームワークにDBICのプラグインが無い時なんか 泣きそうになりませんか?私ならなります>< ちょっとドラフト案ですが、DBIx::Class::SchemaAccesserなるものを作ってみまんた。 使い方は以下を参照のこと。 ご意見求む。datasourceあたりをもっと綺麗にできないかしら。 DBIx::Class::SchemaAccesserの
WEB+DBが発売されてます。 id:naoyaさんの記事はDBICです! 買うべしべし。 WEB+DB PRESS Vol.36posted with amazlet on 06.12.27WEB+DB PRESS編集部 技術評論社 売り上げランキング: 690 Amazon.co.jp で詳細を見る DBICでRを拡張する時の話ですが、WEB+DBにも載っているとおり、 CDBIとは異なりDBを操作する時にResultSetというレイヤを経由して もりもりDBを触るのですが、その為、CDBIで簡単にできていたことができなくなっています。 それはRの拡張です。 例えば弊社の場合、idの代わりにridがユニークなキーになってるので、 ridでレコードを検索する場合があり、 CDBIの場合 retrieve_ridというメソッドをCDBIに生やして、 Proj::Data::Blog->re
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く