短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
dbicに関するkaz_gotoのブックマーク (28)
-
kaz_goto 2008/10/29
-
hide-k.net#blog: TTでDBICのhas_manyなメソッドを使う
よくわからない表題ですが要は・・・ MyApp::Schema::TopicsとMyApp::Schema::Commentsが1:nの関係にあるとして package MyApp::Schema::Topics; use strict; __PACKAGE__->has_many('comments' => 'MyApp::Schema::Comments'); 1; こんなアクションで sub list : Local { my ( $self, $c ) = @_; my $topics = $c->model('Topics')->search({}); $c->stash->{topics} = $topics; $c->stash->{template} = 'list.tt'; } TTで素でやる場合 <html> <body> <ul> [% WHILE (topic =
-
-
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
-
DBIx::Class::Cursor::CachedつかってみたCommentsAdd Star - unknownplace.org - 2007/12/20
舌足らずすぎた。 Model::DBIC: connect_info: - dbi:mysql:table - root - on_connect_do: - SET NAMES utf8 cursor_class: DBIx::Class::Cursor::Cached cache_file: __path_to(tmp/query_cache)__ さっきはこんなconfigで使った場合のコードです。 すばらしすぎる。もっと早く使えばよかったとおもった。 Catalyst::Model::DBIC::Schema で使う場合はこんな感じでOK。 sub new { my $self = shift->NEXT::new(@_); my $cache = Cache::FastMmap->new( share_file => $self->{cache_file} ); $self->s
-
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
-
-
ある環境下のCatalystでDBIx::Class::Schema::Loaderが落ちるのを修正 - ヒルズで働く@robarioの技ログ
久々に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
-
2007/05/07 - memo - unknownplace.org
書き忘れたけどさっきの update_schema.pl は ./script/myapp_update_schema.pl dbi:mysql:tablename username password 見たいな感じで DSN を渡す必要がある。めんどう。 ここら辺があれでまだヘルパーにはなってない。 mizzy.org : Re: DBICとDBIx::Class::Schema::Loader 僕のいろいろな勘違い 僕の中で流行ってる使い方があるのでかぶせて書いておいてみる。mizzy さんの二個目の例を自分ルール化させた感じ？ 作業は一般的なCatalystアプリのディレクトリ構造上であるとして、そこに新しく schema というディレクトリを作成。 そんで、 schema/lib/Schema/{TableName}.pm に各テーブルのリレーション定義とかメソッドとかを自分で書く。
-
mizzy.org : Re: DBICとDBIx::Class::Schema::Loader 僕のいろいろな勘違い
ブログが続かないわけ | DBICとDBIx::Class::Schema::Loader 僕のいろいろな勘違い にて、 とはいえ、僕の稼働中のアプリはすでに手動型のSchema で動いている。スキーマを作り直したら、リレーションの設定を全てしなおさなければならないので、それは現実的じゃない。inflate, deflate の指定は、やっぱりすべてのSchema にかかなきゃだめそうだ。 とあったので、これに関して少し楽ができる方法をコメントしようと思ったけれど、コメント欄ではうまく伝えられる自信がないので、こちらで書いてみることにしました。 load_components で 読み込む方法 DBIx::Class::Schema::Loader ではなく DBIx::Class::Schema を継承したスキーマの場合には、各スキーマファイルに以下の様に書いてあげれば OK です。（既
-
Profile Your Catalyst/DBIC App with QueryLog - One Mo’ Gin - Sometimes Once Isn’t Enough
Months ago I implemented DBIx::Class::Storage::Statistics with the intent of making some sort of profiling tool. I finally got off my ass and did it. DBIx::Class::QueryLog should be on CPAN this weekend. At $work we are replacing a legacy system with one based on Catalyst. One of the deliverables for this year is a new order entry application. Since our customer service folks are used to working i
-
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だけで完結。 と、いうのを社内の人に教えてあげる予定。 最近、一眼レフのカメラがほしくなってきたある
-
DBIx::Simple - Hatena::Diary::Neko::kak 500 Internal Server Error
DBIx::Simpleがいい感じです。 普段はDBIC使うとして、複雑なSQLを実行しなければいけない場合、 DBI直でやったりしますが、DBIx::Simpleつかえばいい感じでかけます。 DBI直でもいいのですがOO風味でかけるのがうれしげ。 こんなん。すげー適当ですけど。 #! /usr/bin/perl use strict; use warnings; use Data::Dumper; use DBIx::Simple; my $db = DBIx::Simple->connect('dbi:mysql:test_dbic','hoge','moge') or die DBIx::Simple->error; for my $row ( $db->query('SELECT id FROM blog')->hashes ) { print Dumper $row; } my
-
Catalyst + Lighttpd + FastCGI + DBIC + Schema::Loader に関する備忘録 :: Drk7jp
ここ数ヶ月 Catalyst を触っていなかったらメキメキと記憶から知識が抜けてました・・・orz 恐ろしいことに DBIC もメキメキと忘れてました・・・orz 僕はどちらかというと OR Mapper を使うよりも SQL 直書きしたほうが理解が早い部類の人間なので DBIC つかって distinct とかするコードを書くのが面倒くさくて仕方がない。なので本業の Sledge ベースのアプリは Model 部分に自前の DBI ラッパー使ってコネクションとかも管理してます。 ※ココ時代と逆行してるんでしょうね・・・ とはいえ忘れたままは悔しいので、最近ちょっとしたアプリを作るために Catalyst を使って書いていろいろメモったのを備忘録として残して自分用に公開。ってか DBIC のことなら DBIx::Class::Manual::Cookbook - Miscellaneous
-
DBIC で+select と+as : ああ、今頃気づくなんて... | ブログが続かないわけ
DBIC でデータをSELECT するときに日付型のデータを好きなフォーマットで取得するのに苦労していました。 単純にSQLでto_date関数などを発行すればいいのですが、そのためにはDBICでselect, as を使わなければなりません。 それがすごく面倒なんですよ。 日付のフォーマットさえ気にしなければ、こうやってデータを取れます。$c->model('DBIC::TranDiary')->search($query_ref);ところが、フォーマットをto_date で整えるためには、こーんな風に書かなければなりません。$c->model('DBIC::TranDiary')->search( $query_ref, { select => [ 'me.diary_id', 'me.user_id', 'me.title', 'me.body', 'me.status', 'me.
-
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のところでそ
-
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
-
hide-k.net#blog: Catalyst::Model::DBIC::Schemaを使ってみた
Catalyst::Model::DBIC::Schemaを使ってみました。 DBIx::Classで新しくなったSchemaモデルをCatalystのModelとして使うクラスなのですが、今までのModelと大きく違うのはモデルをアプリケーションの外に追い出すことが出来る点です。 例えば、複数のアプリケーションで認証情報を使いまわしたい時には便利かと思われます。 まずはスキーマを作ります。(Perl/DBIC - Nekokak's core dumpに大変わかりやすい説明があります。) Schema/ Account.pm Account/ Users.pm Schema/Account.pm package Schema::Account; use strict; use warnings; use base 'DBIx::Class::Schema'; __PACKAGE__-
-
resultset_attributes - Hatena::Diary::Neko::kak 500 Internal Server Error
DBICのresultset_attributesを使うとデフォルトの検索条件とか ソート条件を指定できます。 package Your::Schema::User; use strict; use warnings; use base 'DBIx::Class'; __PACKAGE__->table('user'); __PACKAGE__->resultset_attributes({ order_by => 'id DESC'}); ... 1; こんな感じでresultset_attributesを指定しておいてやると デフォルトでid DESCになってくれる。 例えば $self->model('User')->search( { name => 'nekokak' } )->first;こんなのを実行すると SELECT me.* FROM user me WHERE nam
-
DBIx::Class で sql_maker が生成した SQL をロギングする方法
DBIC いろいろ使って検証を続けているのですが、O/R Mapper って当たり前だけど万能じゃぁないなぁ〜とすごく思う今日この頃。正直、リレーションとか張りまくってる場合、自前で JOIN とか View 定義して書いた方が遙かに効率の良い SQL が記述できる。 複雑な SQL を表現するには、O/R Mapper だと逆に見づらいなぁ〜と思ったり。 とはいえ、単純な SQL の場合はやはり便利。コードも見た目、OO っぽくてかっこいいし。 でも、どうにも解析できなかったことが一つ。DBIC しか見てないんですが、sql_maker が生成した SQL をロギングする方法がわかりません。なんかコードを深追いしていくと、 メンドウなので、モジュールにしてなくってとってつけたような感じで実現。たとえば、Catalyst だと MyApp.pm で use UNIVERSAL::requi
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました