WEB+DB PRESS vol33の「ライブドア構築ノウハウ大公開」でClass::DBIの永続化を切るには、Ima::DBIの内部でクロージャとして生成されるdb_Mainをオーバーライドすれば永続化を切ることができるという記述がありました。 これなんですが、先日あるアプリを作成しているときに、db_Mainをオーバーライドしても永続化されてしまうという現象にあいました。 いろいろ調べたり、にぽたんとかに聞いたりした結果、db_Mainをオーバーライドしているクラスで __PACKAGE__->set_db() もしくは __PACKAGE__->connection() をしていたのが悪かったということが判明しました。なぜなら __PACKAGE__->set_db() もしくは __PACKAGE__->connection() をすると、Ima::DBIではなくClass::DB
お仕事でレンタルサーバー上でCGIを書く羽目になったのですが、root権限はおろかシェルも使えない環境なのでCatalystにどっぷりつかっていたボクとしては面倒くさくて気が狂いそうです。 特にDB周り。 DBI直たたきなんて非人間的な作業をやっているとバグつぶしだけで頭がおかしくなりそうです。 で、なんとかClass::DBIだけでも使えないか調べて見ました。 CDBIが依存しているクラスでXSを使っているのはversionとCloneだけです。 それならある程度環境が整っているレンタルサーバーならなんとかなるだろうってことで調べて見ると、都合のいいことにversionは--perl_onlyオプション付きでMakefile.PLすればPure Perlなクラスを作成してくれるし、CloneはClone::PPなるPure PerlなCloneクラスがありました。 で、やってみました。
CDBI を使ってて、 __PACKAGE__->set_sql(Foo =><<'SQL'); SELECT __ESSENTIAL__ FROM __TABLE__ WHERE foo = ? AND bar = ? SQL sub do_something { my($class, $foo, $bar) = @_; my $sth = $class->sql_Foo; $sth->execute($foo, $bar); return $class->sth_to_objects($sth); }Class::DBI::Plugin::Iterator を use しておいてこんなんしとくと、CDBI の $VERSION が古いやつの場合に、scalar context で動いてくれない。 動いてくれんというか、空っぽの Iterator が返る。 3.x 系ではちゃんと動いたん
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Class::DBI使ってるときにqueryにどれだけ時間掛かってるか見てみたかったので作ってみた。 sth_to_objectsをredefineする感じ。 package Class::DBI::Plugin::QueriesTime; use strict; use warnings; use Time::HiRes qw( tv_interval gettimeofday ); use vars qw($VERSION); $VERSION = 0.01; sub import { my $class = shift; my $pkg = caller(0); my $befor_query; no strict 'refs'; no warnings 'redefine'; *{"$pkg\::sth_to_objects"} = sub { my ($class, $sth,
とてもステキなペアを発見。Class::DBI::Loaderを使うと、DB上の全てのテーブルをClass::DBIとして定義してくれるわけだが、たいていの場合実際のデータオブジェクトにさらにメソッドを足したりしたい事が多い。日記才人の場合、例えばPostgreSQLのストアドプロシージャを使う事が多く、それを適時呼んでいる： package NikkiSite::Data::Diaries; use strict; use base qw(NikkiSite::Data::Base); __PACKAGE__->set_sql(latest => SELECT * FROM nsRetrieveLatestDiaries(?) EOSQL まぁ、これを使う所はとりあえず置いておいて、これをClass::DBI::Loaderが定義する情報の上に足したいので、できればこのlib/Nikk
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
DBIx::ClassのMLに流れた情報を自分なりに試す。 ベンチの取り方とかに問題あれば突っ込みお願いします。 テーブル構造はこんなの mysql> desc order_cust; +-------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+----------------+ | id | int(10) | | PRI | NULL | auto_increment | | name | text | | | | | +-------+---------+------+-----+---------+----------------+ 2 rows
Class::DBIで複数データベースを扱う+register_cleanup Class::DBIで同じ構造の複数データベース扱う時には、まかまかさんのClass::DBI::Plugin::MultiDatabases(後で知った)や、Class::DBIのWikiにあるけど、さらにmod_perl上でのTips ちょっと実際書いたコードと違うので全くこの通りでうごくかどうか心配なのですが、複数データベースに接続をするモジュールを下のように書いてみる。 package Object; use strict; use DBI; use base qw(Class::DBI); use Class::DBI::Plugin::NoCache; use MyConfig;#データベースの接続情報を返すモジュールとする __PACKAGE__->mk_classdata('dbhandles'
以前 Class::DBI で疑似的カラムを扱うというタイトルで、Class::DBI::Plugin::PseudoColumns という CPAN モジュールを紹介したことがありました。 で、そのエントリを見てみるとこんなトラックバックをいただきました。 浅倉卓司＠blog風味？ - Class::DBI::Plugin::PseudoColumnsって便利じゃん、と思ったけれど、「Class::DBI で疑似的カラムを扱う」を読んで「こりゃ便利」と思ったけど、でも、最近はPerlとPHPの混用が多いので使えないのですよね……。 というわけで、シリアライザを指定できるとうれしいかも。 PHP::Serializationを使ってPHP側に合わせてあげるのがPerlクオリティだと思うし。場合によってはJSONで突っ込むのもありかもしれないので。確かにシリアライザは指定出来たほうがいいです
ふと Class::DBI で、update_from_sql() というメソッドを定義したくなった。 あんま面白くないので、読みたい人だけ読みたまへ。 で、こんな感じのものを、親 class 内に定義してみた。 __PACKAGE__->set_sql(UpdateFromSQL =><<''); UPDATE __TABLE__ SET %s WHERE %s sub update_from_sql { my($class, $values, $sql, @bind_args) = @_; my @update_columns = (); my @update_values = (); while (my($colname, $value) = each %$values) { push @update_columns, $colname; push @update_values, $
Class::DBI::SweetでのJOIN Class::DBI::Sweetのjoinをつかった検索を試してみた。 ソースコードは作っているアプリケーションからの抜きだしなので足りないところがあるかも。 EntryとそのTagを想定して、 package Entries; __PACKAGE__->table('entries'); __PACKAGE__->columns(All=>qw/id title text created_on/); __PACKAGE__->has_many("tags"=>'Tags'); 1; package Tags; __PACKAGE__->table('tags'); __PACKAGE__->columns(All=>qw/id entry_id tag/); __PACKAGE__->has_a('entry_id'=>'Entries'
「Class::DBI で疑似的カラム」をちょっと機能強化と、Class::DBIにStorable::freezeなデータ nipotanさんの「Class::DBI で疑似的カラムを扱う」で(自演)紹介されてるClass::DBI::Plugin::PseudoColumnsなんですが、ObjectやHASHをStorableでSerializeしてデータベースに突っ込む方法を便利にできるプラグインとしてちょっと気になった。 ただ、２つほど弱点があって create/insert時に使えない SerializeがData::Dumperオンリー このあたりが解決されると使いやすいと思うのでいじってみた。 podを書いてないんだけど、ソース一式はこちら→Class-DBI-Plugin-SerializeColumns-0.01.tar.gz。なかなかうまく動かなくていろいろ変更している
NAME Class::DBI::Plugin::PseudoColumns - an interface to use some pseudo columns SYNOPSIS package Music::CD; use base 'Music::DBI'; Music::CD->table('cd'); Music::CD->columns(All => qw/cdid artist title year reldate properties/); use Class::DBI::Plugin::PseudoColumns; Music::CD->pseudo_columns(properties => qw/asin tag/); use Music::CD; my $cds = Music::CD->search(artist => 'Steve Vai'); while (my
最近、SQL で WHERE 句に入らず、ORDER BY やら GROUP BY もされず、かつ MAX() だとか MIN() だとかを求められる必要もない、言うなれば「取るに足らない値」とかを、個別のカラムに持たず、そういうのを一気にまとめて text 型のカラムに入れたりすることがあったりする。 例えば、住所録を作ろうなんつって、テーブルを組みたいわけだが、そもそも WHERE 句に入る要素なんて名前ぐらいしかないなぁ…という場合は CREATE table address ( id int unsigned NOT NULL auto_increment, name varchar(255) NOT NULL default '', props text, PRIMARY KEY (id), KEY (name) ); こんなようなテーブルを一個作っておいたりして。 要するに、n
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く