After possibly the longest and most irritating development cycle in DBIC's history, 08100 is released! Important changes in this release are: - deploy() and Schema::Versioned are no longer experimental - multi-create has been substantially rewritten and should now work for as many cases as we've had thrown at us - subselect support via SQL::Abstract 1.50 + $rs->as_query - InflateColumn::Dat
DBIx::Class::ResultSetManager - scheduled for deletion in 09000 - search.cpan.org DBIx::Class::ResultSetManager never left experimental status and has now been DEPRECATED. This module will be deleted in 09000 so please migrate any and all code using it to explicit resultset classes using either __PACKAGE__->resultset_class(...) calls or by switching from using DBIx::Class::Schema->load_classes()
今まで datetime なカラムの検索は $schema->resultset('Entries')->search( { created_on => { '>=' => $day_start, '<=' => $day_end, } } ); とかしてて、いちいち 00:00:00 〜 23:59:59 まで用意してあげてたんだけど、隣の人に聞かれて、SQL だったら select * from entries where date(created_on) = '2008-08-21'; こう書くよなぁ、DBIC だとどう書けば、とか思って $schema->resultset('Entries')->search( { 'date(created_on)' => $day, } ); こう書いたらできた >_
my $rs = $schema->resultset('Order')->search( {}, { select => [ { date_trunc => [ 'day', 'created_on' ] } { count => 'id' } ], as => [qw/created_day order_count/], group_by => 'created_day', order_by => 'created_day', } ); で動くかと思いきや動かないので my $rs = $schema->resultset('Order')->search( {}, { select => [ \"date_trunc ('day', created_on) as created_day", { count => 'id' } ], as => [qw/created_day orde
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践 奥さん本人の中でブームが去った感もあるRDBMSで実現するフレンド・タイムライン処理ですが、そういえばDBICで使ってみたのを思い出したので晒してみます。 要はDBICからストアドプロシージャの叩き方を知りたかっただけなんですけどね。 パッケージ名はWebインターフェースはどーせCatalystで作るでしょってことでCatalyst + Twitter = Catatter…って安直なネーミングですね。 記事中ではプッシュ型とプル型が紹介されているのですが、データ量やfollow, removeの際のコストとか考えたらプル型の方が好みかなってことでプル型を採用してみました。 また、基本的にスキーマやストアドプロシージャはオリジナルと同じですが、DBICでPKをマルチカラムにするとめんどっちーのでサロゲートキーを
と言う訳で自分なりに色々調べてみた。 テスト用データベース定義 CREATE TABLE `User` ( `user_id` bigint(20) NOT NULL auto_increment, `name` varchar(255) character set latin1 default NULL, `created_on` datetime default NULL, `updated_on` datetime default NULL, PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `Book` ( `book_id` bigint(20) NOT NULL auto_increment, `name` varchar(255) character set latin1 de
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
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
resultset_attributesをつけてると便利だったりもするんですけど、 resultset_attributesに検索条件を入れてると うざい場合があって、同僚が悩んでたので↓みたいにしてみそらしどといってみた my $schema = $self->model; { local $schema->source('Hoge')->{resultset_attributes} = ''; my $rs = $self->model('Hoge')->search; $rs->all; } my $rs = $self->model('Hoge')->search; $rs->all; まあこんなんでどうですかな {resultset_attributes}をさわるのはどうなのよという話もありつつ。
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
舌足らずすぎた。 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
てなわけでRubyはやってません がCodeReposにDBIx::Class::Tree::NestedSetをCommitしてみました。これのアルゴリズムに関しては[mysql 12071] 階層化されたデータをMySQLで扱うを参照ということで省略。ここに書いてあるのと違う点としては、親ノードの付け替え用にmvgフラグを必要としています。(インスパイア From DBIx::OO::Tree) メソッドはDBIx-Class-Treeをパクリ準拠していますのでテストもパクリ準拠してまったく同じ(あ、mvgカラムは追加してるけど)テストを通しています。 あとはDBIx::OO::Tree,DBIx::Tree::NestedSetあたりをパクリ参考にしてみました。 でもってTODOにも書いてるのですが、rootノード取得用にResultSetManagerなメソッドを生やしたいんですが
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ページを開く
