DBIC使ってて悩まされていたので使用自体に懐疑を覚えたところで、そもそもの使用に関していろいろアドバイスいただいたのでまとめ。 ・JOINするくらいならO/R Mapper使わない方がいい ・DBICではメンテやチューニングの面からあまり複雑なことしない方がいい。複雑なことするなら自分で書く方がまだいい ・DBIx::Skinny みたいなもっと簡潔なのも最近はあるよ
![DBIx::Class って O/R Mapper としてどこまで本気で使えるの?](https://cdn-ak-scissors.b.st-hatena.com/image/square/413cd840767042b0f28162e9e87be98c8d4f4917/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F44da0c533d983757fdf0e1fe5e5fff8d-1200x630.png)
追記です コメントとブクマで今のところ experimental と書いてあるよ! と教えてもらいました。気づいてなかったです。id:nihen さん、コメントくれた人、ありがとう。 This option is experimental and may change in future versions. Catalyst::Wiki もこれ書いた方が良さそうですね。書けるのかな。 それにしても、DBD 側でできると良いに越したことないので、早く確定して欲しいですね! 追記2 あー、でもこれ、4.00からずっとこのままだ。かれこれ2年くらい experimental なんですがw Catalyst::Wiki に書いて来ちゃったけどw ここから元の内容 lyokato さん経由で woremacx さんに教えてもらった Using Unicode - Catalyst::Wiki に書い
ハマったメモ。 さてまた今回も若干適当な記事だけども、メモということでお許し願いたい。 ってか誰も言及してないっぽいんだけどもしかしてこの現象うちだけ? とにかくタイトルの通りで、検証時の各モジュールのVERSIONは以下の通り。 DBD::mysql-v4.005 DBIx::Class-v0.08100 前回のDBD::mysqlでSegmentation faultの件は無事解決したものの、今度はDB再接続時に文字化け発動でゲンナリしてました。 でログとか見てるとどうもDBICのon_connect_doで指定しているSET NAMES UTF8がDB再接続時に動いてないことが判明。 myapp_server.plだとちゃんとSET NAMES呼ばれるんだけどmod_perlだと何故か呼ばれない。 ってことでmod_perlに関係有りそうな部分をひたすら調べていたところ、mysql_
なんか良く分からんけどSegmentation faultが出て泣きそうだったんだけどやっと原因がわかったっぽい感じなのでメモしとく。 とりあえず環境は下記 CentOS 5.2 Apache 2.2.9 Perl v5.8.8 mod_perl 2.0.4 MySQL 5.0.51b 現象としてはサイトを数時間放置してアクセスすると必ずセグるというもので、当初は何がなんだか分からないL状態でした。 で、coreファイルを解析したところ、 Program terminated with signal 11, Segmentation fault. #0 0x048be024 in mysql_send_query () from /usr/local/mysql/lib/mysql/libmysqlclient.so.15 というメッセージが。どうやらmysqlに問題があるっぽいことがわか
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践 奥さん本人の中でブームが去った感もあるRDBMSで実現するフレンド・タイムライン処理ですが、そういえばDBICで使ってみたのを思い出したので晒してみます。 要はDBICからストアドプロシージャの叩き方を知りたかっただけなんですけどね。 パッケージ名はWebインターフェースはどーせCatalystで作るでしょってことでCatalyst + Twitter = Catatter…って安直なネーミングですね。 記事中ではプッシュ型とプル型が紹介されているのですが、データ量やfollow, removeの際のコストとか考えたらプル型の方が好みかなってことでプル型を採用してみました。 また、基本的にスキーマやストアドプロシージャはオリジナルと同じですが、DBICでPKをマルチカラムにするとめんどっちーのでサロゲートキーを
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
MVCのモデルはDBじゃなくてもいいんだよ id:charsbarさんが、先ほど書いたエントリに関して 後半その通りなわけですが、CatalystはModel::DBIC系のせいでMVCが誤解されてるのよねー と言っておられる。たしかにその通り。「モデルってDBでしょ?」みたいな印象が一般的にあると思う。 そういう印象を持ってる人に説明すると、「モデルを作る」って何かというと、DBのようなストレージにあるものをどうこうする、ではなくて「データに対する操作を抽象化したものを作る」ということです。例えば、ブログを作ると、Blog、BlogEntry、BlogUserみたいなモデルを作ります。そしてその操作方法はこんな感じ: # ブログを登録するみたいなAPI MyApp::Model::Blog->create({ user => $blog_user, title => $title, .
DBIx::Class::Schema::Loader を使うとデータベースのスキーマを自動的にモデルに変換してくれます。ここでは、さらに複数のデータベースのスキーマを動的に作成して、マルチベータベースを使うための方法を紹介します。 DBIx::Class::Schema::Loader には make_schema_at というメソッドが用意されているのでこれを使います。 HogeSchema.pm スキーマローダを継承したクラスです。 package HogeSchema; use strict; use warnings; use base qw/DBIx::Class::Schema::Loader/; sub make_schema_at { return DBIx::Class::Schema::Loader::make_schema_at(@_); } 1; test.pl
ちょっと煮詰まったので、他人のコードを読むことに。CatalystのWikiにはExampleなるセクションがあって、いくつかアプリケーションが紹介されているのだけど、ことごとくダメ(動かない、確かにCatalyst使っているけどなんか違う、ソースがダウンロードできないとか)。mojomojoが参考になりそう。 で、読んでいるとコメントをデータベースに突っ込む際に $c->model("DBIC::Comment")->create_from_form($c->form); なんてしてる。えー、そんだけでいいのか。 DBIx::Class::WebForm - CRUD Methods For DBIx::Class FormValidatorとDBIx::Class::WebFormの組み合わせはいい。 なんつーか、こういうショックってVimに似てる(Tip #1: the super
DBICで論理削除をしたくなったので調べていたのだが、うまく書く方法がイマイチなかった。 まず、削除フラグを常にチェックするようにするのは簡単で、テーブルクラスに __PACKAGE__->resultset_attributes({ where => { deleted => undef }}); とか書いてくだけでつねにWHERE句に deleted IS NOT NULL が入るようになる。これはマニュアルに書いてある通り。 問題は削除するときで、テーブルクラスで delete 定義してそこで update({ deleted => 1 }) とかやればいいかなと思いきや、そうすると cascade delete 効かなくなってしまっていやだ。 DBICのrowに対するdeleteチェーンは大まかに ユーザー定義テーブルクラスでのdelete (定義されてる場合)DBIx::Clas
ResultSetにメソッドを生やしたい訳です。ResultSourceのメソッドにresolve_prefetchっていうのがあって、prefetchとかjoinで指定するrelationのリファレンスを渡すとcolumnを返してくれるものがあります、{ blogs => 'user_id' }みたいなやつです。ただしそのままではlookupに使えないのと自分が無いのでちょっとWrapしたい訳です。 巷ではResultSetManager使うらしいんですが、Loader使ってるので使えません。で、自分のResultSetを作って my $source = $schema->resultset('Moge')->result_source; $source->resultset_class('MyApp::ResultSet'); みたいな感じでresultset_classを指定して自分
追記 名前変更してcodereposに上げてみました。 http://svn.coderepos.org/share/lang/perl/DBIx-Class-AsArrayHash/ 独自にキャッシュしたいときや、viewがオブジェクトをサポートしてない時とかに必要にかられる。 コンポネント DBIx::Class::ResultSetX package DBIx::Class::ResultSetX; use strict; use warnings; use base qw( DBIx::Class ); __PACKAGE__->load_components(qw/ResultSetManager/); sub searchX : ResultSet { my $self = shift; my $cond = shift || {}; my $args = shift || {
舌足らずすぎた。 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でバックエンドとの接続が切れた時などに再接続する際の挙動が、0.07x と 0.08x で異なるようなのでメモ。確認したのは PostgreSQL の場合です。 動作確認スクリプトは末尾に。動作は以下の流れ。 connect() resultset から find() バックエンドをkill resultset から find() 0.07006 の場合。 $ perl -IDBIx-Class-0.07006/blib/lib/ dbic.pl DBIx::Class->VERSION: 0.07006 get ok 19115 killing 19115 FATAL: terminating connection due to administrator command get ok正常に再接続可能。 0.08007 の場合。 $ perl -IDBIx-Class-0.080
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く