DBIx::Skinnyを使った際のCache方法考察 - Hatena::Diary::Neko::kak 500 Internal Server Error
DBIx::SkinnyにはDODやData::Modelのようにキャッシュを透過的に扱う 便利機能はありません。 無いのでラッパーを書きませう。 毎度の事でデモは http://github.com/nekokak/p5-dbix-skinny-sample/tree/master/cache/ に置いてあります。 ユーザテーブルがあるとします。 CREATE TABLE user ( id INTEGER PRIMARY KEY AUTOINCREMENT, name VARCHAR(255) NOT NULL, UNIQUE(name) ); ユーザの情報をキャッシュからひけなければDBから引っ張って キャッシュしておき、次に使う時はキャッシュデータを使うという典型的なパターンです。 userテーブルの定義などはこのようにします。 今回はinflate/deflateも一緒にやってみ
DBIx::Skinny - Hatena::Diary::Neko::kak 500 Internal Server Error
いまさっきcodereposにDBix::Skinnyというものをimportしました。 http://coderepos.org/share/browser/lang/perl/DBIx-Skinny 昨今のDBICブームで利用者は増えてきたんですが、いろいろ使うにあたって、 ここまでORマッパーでいろいろ（JOINしたり、キャッシュしたり）やるのはどうなんだとか、 うんたらかんたら考えたら自分で作ってしまえてのが動機でした。 DBICははっきり言ってどでかいライブラリなので一からソースを読むのがかなり大変です。 仕事で使ってる関係上、仕方なく見ることもありますが、キツい。 あと、DBICを使っているとJOINしたSQLがある意味簡単に発行できるので 重宝するのですが、ぶっちゃけどういうSQLが発行されているか全部ちゃんと見てる人って どれくらいいるのだろうと思ったり。 DBICによって
DBIx::Class::ProxyTable - Hatena::Diary::Neko::kak 500 Internal Server Error
前にhttp://d.hatena.ne.jp/nekokak/20070824/1187941930ってのをかきましたが それをモジュール化してみた http://coderepos.org/share/browser/lang/perl/DBIx-Class-ProxyTable とりあえずMySQLとSQLiteでつかえる（はずです 使い方 package Your::Schema; use base 'DBIx::Class::Schema'; __PACKAGE__->load_classes(qw//); package Your::Schema::Log; use base 'DBIx::Class'; __PACKAGE__->load_components(qw/ProxyTable Core/); __PACKAGE__->table('log'); __PACKAGE
DBICでテーブル名切替の術 - Hatena::Diary::Neko::kak 500 Internal Server Error
アプリを作ってると色々ログ系をDBに保存しておきたかったりするのですが、 ログテーブルって結構でかくなってしまう運命です。 DBによってはテーブルサイズがでかくなると検索効率が落ちてしまったり ちょくちょく問題になってしまうのですが、 ログテーブルを年月ごととかで分割すると結構さくさく扱えたりします。 ただ、普通にDBIC使ってると分割したログテーブル毎にスキーマを用意する必要が でてきてしまうです。 例えば access_logってテーブルがあるとして、これを年月で分割して保存させるばやい、 access_log : Proj::Schema::AccessLog access_log_200706 : Proj::Schema::AccessLog200706 access_log_200707 : Proj::Schema::AccessLog200707 access_log_20
DBICコネタ - Hatena::Diary::Neko::kak 500 Internal Server Error
find_or_createをよく使ってる人は find_or_newを使うようにしたほうがいいお。 たとえば、 my $member = $self->model('Member')->find_or_create( { name => 'nekokak' } )->update( { moge => 'kekekek' } ); とかすると、 searchしてinsertしてupdateとクエリが実行されるけど、 find_or_newを使えば、 my $member = $self->model('Member')->find_or_new( { name => 'nekokak' } )->insert( { moge => 'kekekek' } ); searchしてinsertだけで完結。 と、いうのを社内の人に教えてあげる予定。 最近、一眼レフのカメラがほしくなってきたある
search_literal - Hatena::Diary::Neko::kak 500 Internal Server Error
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使わな
DBIx::Class::SchemaAccesser - Hatena::Diary::Neko::kak 500 Internal Server Error
DBIx::Class::SchemaAccesserなるものを作りました。 ラボで公開ちう。 http://code.mfac.jp/trac/browser/CPAN/nekokak/DBIx-Class-SchemaAccesser/ Catalystとかのフレームワークを使っている場合は DBICのオブジェクトを毎回作るのはフレームワークのプラグインとかが 簡単＆ほぼ勝手にやってくれるからいいのですが、 コマンドラインのツールとかフレームワークにDBICのプラグインが無い時なんか 泣きそうになりませんか？私ならなります＞＜ ちょっとドラフト案ですが、DBIx::Class::SchemaAccesserなるものを作ってみまんた。 使い方は以下を参照のこと。 ご意見求む。datasourceあたりをもっと綺麗にできないかしら。 DBIx::Class::SchemaAccesserの
MoFedge::Data::DBIC::Schema::Loader - Hatena::Diary::Neko::kak 500 Internal Server Error
今までMoFedge::Data::DBIC::Schemaを使う時は、 以下のような感じでした。 package TestDBIC::Schema; use strict; use warnings; use base qw(MoFedge::Data::DBIC::Schema); __PACKAGE__->load_classes( ); 1; package TestDBIC::Schema::Member; use strict; use warnings; use base 'TestDBIC::Schema'; __PACKAGE__->table('member'); __PACKAGE__->add_columns( qw/ id rid name created_on timestamp / ); 1; こんな感じにスキーマが増えると、対応するモジュールを作ってました。
DBIC::Schema::Loaderを久々に使ってみる - Hatena::Diary::Neko::kak 500 Internal Server Error
普段から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
DBICのRの拡張 - Hatena::Diary::Neko::kak 500 Internal Server Error
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
DBICでの簡単キャッシング - Hatena::Diary::Neko::kak 500 Internal Server Error
DBICで簡単にお金が借りることができます（ちが まあ、面白くないのでやめておきますが、DBICは かなりパフォーマンスに気を使った設計なのは周知の事実なのでつが、 キャッシュを使うことでよりパフォーマンス向上が図れます。 例えば my $itr = $self->model('Member')->search({},{}); while (my $member = $itr->next) { warn $member->id; } $itr->reset; while (my $member = $itr->next) { warn $member->id; } こんな感じの処理があったとします。 Memberテーブルを二度処理するみたいな。 ちなみに同じオブジェクトを使う時は $itr->reset; こうしてやればイテレータがリセットされます。 この場合、２個のwhileのところでそ
MoFedge::Data::DBIC::Schemaのソースはっつけてみた - Hatena::Diary::Neko::kak 500 Internal Server Error
はてダでシンタックスハイライトがでけるようになったので！ package MoFedge::Data::DBIC::Schema; use strict; use warnings; use base qw/MoFedge DBIx::Class::Schema/; our $VERSION = '0.02'; use UNIVERSAL::require; use Switch; use Data::Page::Navigation; use Lingua::EN::Inflect; __PACKAGE__->load_components(qw/ +MoFedge::Data::DBIC::AutoSet +MoFedge::Data::DBIC::FromSledge +MoFedge::Data::DBIC::AutoInflateDateTime AsFdat PK::Auto
MoFedge::Data::DBIC::Schemaの解説してみますかね - Hatena::Diary::Neko::kak 500 Internal Server Error
MoFedge::Data::DBIC::SchemaってのがMFのラボで公開されてるのですが、 http://code.mfac.jp/trac/browser/MoFedge-Data-DBIC-Schema/ いまいち分からないらしい。 DBIx::Class::Schema::Loaderとなにがどう違うのかとかとか。 まあ、基本DBIx::Class::Schema::Loader http://search.cpan.org/dist/DBIx-Class-Schema-Loader/ これを使っとけばいいんじゃないでしょうか。 終わり（マテ MoFedge::Data::DBIC::Schemaって何をヤッテクレル人なのかを かるーく書いてみようと思う。 load_componentsを書くところを１箇所にするためのもの。 MoFedge::Data::DBIC::AutoS
DBIx::Class::StorageReadOnly - Hatena::Diary::Neko::kak 500 Internal Server Error
とかいうのをでっち上げてみた。 スレーブにinsertとかupdateとかかけて死ねるのはイヤンなので。 まあ、開発環境のDBもちゃんと設定しておけば こんなの使わなくても気づくのですが、保険です。 package DBIx::Class::StorageReadOnly; use strict; use warnings; use base 'DBIx::Class'; use Carp::Clan qw/^DBIx::Class/; sub insert { my $self = shift; if ($self->result_source->schema->{__READ_ONLY_CONNECTION}) { croak("This connection is read only. Can't insert."); } $self->next::method(@_); } sub
DBIC::DigestColumns::Lite - Hatena::Diary::Neko::kak 500 Internal Server Error
とりあえず決め打ちでDigest::SHA1でいいから簡単に使えるのを作った。 CPANにアップされているDBIC::DigestColumnsは設定項目が大杉。 そんなにいらんし。 昔オイラもDBIx::Class::DigestColumnsを作ってDBICのMLにながしてて 放置してたらだれかが別で作ってアップした。 なので同じ名前空間はつかえねーってことでLite。 使い方は __PACKAGE__->load_components(qw/DigestColumns::Lite PK::Auto Core/); とかしておいてやって。 スキーマの方で package Proj::Schema::User; .... __PACKAGE__->digest_columns('login_pw'); __PACKAGE__->digest_key('no not yet!!'); とか
countしたものにorder by - Hatena::Diary::Neko::kak 500 Internal Server Error
http://en.yummy.stripper.jp/?eid=448071 DBICではたぶん発行するSQLのカラムに別名をつけられないみたいなので スカラーリファレンスでしかたないんじゃないすかね。 どしても嫌だったら、 my @results = reverse sort {$a->get_column('posts_count') <=> $b->get_column('posts_count')} $self->model('Hoge::User')->search( { ## nothing }, { select => [ 'me.user_id', { count => 'me.user_id' } ], as => [qw/ user_id posts_count /], group_by => ['me.user_id'], } ); for my $data (@r
DBICでネストしたループ - Hatena::Diary::Neko::kak 500 Internal Server Error
そういえばとあるところで質問を受けたので。 その質問を補う形で。 DBICを使った場合でも普通にネストしたループは使えるわけですが、 TTの場合。 [% WHILE (blogger = blogger_ite.next) %] [% FOR entry IN blogger.entries %] URL:[% entry.url %] [% END %] [% END %] こんな感じです。 くるくる回ってくれます。 普通にPerlの処理でもこんな幹事 my $blogger_ite = $self->model('Blogger')->search; while (my $blogger = $blogger_ite->next) { for my $entry ( $blogger->entries ) { print $entry->url,"\n"; } } こんな荒業もできます
add_unique_constraintで行かない - Hatena::Diary::Neko::kak 500 Internal Server Error
naoyaさんから突っ込まれましたが、まさにそのとおしでした＞＜； http://naoya.g.hatena.ne.jp/naoya/20061117/1163769268 ふつうにadd_unique_constraintしていなくても my $user = $self->model('User')->find( { rid => 'WFC2nT4MLl' } ); これできますね。 普通に$self->searchしてるだけですし。 $rs->_resolved_attrs->{collapse}を見て、 $rs->nextにするか$rs->singleにするかを分けてるだけ。 ちなみに、 my $user = $self->model('User')->find( { hoge_id => 11 }, { order_by => 'me.id ASC' } ); こういう感じでse
many-to-manyを殴り書き - Hatena::Diary::Neko::kak 500 Internal Server Error
今のところ、あまり必要に迫られているわけではないのですが、 覚書程度にDBICのmany-to-manyを試してみます。 Memberテーブル：Addressテーブル = n : m みたいなな感じで。 package Proj::Schema::Member; use strict; use warnings; use base 'Proj::Schema'; __PACKAGE__->table('member'); __PACKAGE__->add_columns(qw/ id rid name created_on timestamp /); __PACKAGE__->set_primary_key(qw/id/); __PACKAGE__->has_many('member_address' => 'Proj::Schema::MemberAddress','member');
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBICねたの途中ですが。。 - Hatena::Diary::Neko::kak 500 Internal Server Error
