タグ

dbicに関するoverlastのブックマーク (30)

  • DBIx::Class::Manual::Cookbook - レシピいろいろ - perldoc.jp

    名前¶ DBIx::Class::Manual::Cookbook - レシピいろいろ レシピ¶ 検索¶ ページ処理された結果セット¶ When you expect a large number of results, you can ask DBIx::Class for a paged resultset, which will fetch only a small number of records at a time: 結果セットが膨大になりそうなら、ページ処理された結果をDBIx::Classで取得できます。 一回に、少しのレコードしかとってきません: my $rs = $schema->resultset('Artist')->search( undef, { page => 1, # page to return (defaults to 1) rows => 10, #

  • http://kerolin.jspeed.jp/Computer/Linux/dbicql070507.html

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • ゆーすけべー日記

    サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ

    ゆーすけべー日記
  • DBIC::Schema::Loader 使う時のリレーションとか - Hack Forever改めhi-rocksのはてなダイアリー

    いきおいついでにもういっちょ。 DBIC::Schema::Loader 任せってわけにいかないのは言うまでもないので、なんとかしてやらなきゃなりませんね。 んで、最初から「convention over configuration」な設計ができてれば MoFedge::Data::DBIC::Schema のように半自動化することもできると思いますが、すでにそうでもない感じwになってしまってる場合の対応を考えてみました。 まあ、結局のところ「規約じゃなくて設定」になるわけなんですが。 とりあえず、こんな設定ファイルをYAMLで書いて、 artist: relationship: cds: - has_many - cd - artist_id utf8_columns: - name cd: relationship: artist_id: - belongs_to - artist t

    DBIC::Schema::Loader 使う時のリレーションとか - Hack Forever改めhi-rocksのはてなダイアリー
  • DBIC でスカラーリファレンスを使え | ブログが続かないわけ

    以前のエントリでも紹介しましたが、DBICでSQLの関数を使うときはスカラーリファレンスが活用できます。そのエントリでは、INSERTやUPDATEのときにスカラーリファレンスを使う例を示しましたが、SELECTのときにも同じことがいえます。 前回のSELECT時に複雑な関数を使うということも、このスカラーリファレンスを使えばできるということを教えて頂きました。 [DBIx::Class][DBIC][perl] DBIx::Classで複雑な関数を使う:101号室より愛をこめて 前回のコードの下記部分は{ ' ' => '( YEAR( CURDATE() ) - YEAR( birth ) ) - ( RIGHT( CURDATE(), 5 ) < RIGHT(birth, 5 ) )' }, 下記のように書けます。¥ "(YEAR(CURDATE())-YEAR(birth)) -

    DBIC でスカラーリファレンスを使え | ブログが続かないわけ
  • DBIx::Class::Relationship

    mst: Matt S Trout (project founder - original idea, architecture and implementation) castaway: Jess Robinson (lions share of the reference documentation and manuals) abraxxa: Alexander Hartmaier acca: Alexander Kuznetsov acme: Leon Brocard aherzog: Adam Herzog Alexander Keusch alexrj: Alessandro Ranellucci alnewkirk: Al Newkirk Altreus: Alastair McGowan-Douglas amiri: Amiri Barksdale amoore: Andre

    DBIx::Class::Relationship
  • Schema::Loader with CatalystComments

    Catalyst::Model::DBIC::Schema を使う。 この Model は大きく3つの使いかたがある。 単純に既に存在する Schema クラスを使用するSchema::Loader で既存の DB から Schema クラスを生成し、それを使用するSchema::Loader で既存の DB から Schema::Loader クラスを生成し、それを利用する。 1 はまず Schema クラスをどこかに作ってあり(My::Schemaと仮定する)、それをそのまま Catalyst::Model として利用する。 ./script/myapp_create.pl model DBIC DBIC::Schema My::Schema で、MyApp::Model::DBIC が作成される。この My::Schema に connection なんかが定義されていてそれを使う場

  • 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の

    DBIx::Class::SchemaAccesser - Hatena::Diary::Neko::kak 500 Internal Server Error
  • DBICのRの拡張の必要性 - Hatena::Diary::Neko::kak 500 Internal Server Error

    http://d.hatena.ne.jp/hi-rocks/20061228/1167291723 結局、ResultSetクラスにメソッド生やしちゃうと、全部のSchema(テーブル)でそのメソッドが共有されちゃう その通りです。 こちらについては、findのように共通メソッドとして使うものだけを考えています。 例のretrieve_ridはどのスキーマでも使いたいメソッドになるので。 まあ、例が悪かったりもしますが。 MoFedge::Data::DBIC::ResultSetRegisterをもっと作りこめば このスキーマからしか実行できないぜ!とかもできますが、 EXPERIMENTAL!! です。オイラもつかってません>< ちなみにDBICでは、実はスキーマ毎のResultSetの拡張はあんまり必要ないかなとか思ってます。 CDBIの場合はset_sqlしたりなんやかんや動的に

    DBICのRの拡張の必要性 - Hatena::Diary::Neko::kak 500 Internal Server Error
  • DBICのRの件 - Hack Forever改めhi-rocksのはてなダイアリー

    僕も最近ようやくDBICを触り始めました。まだ手探りな感じですが、とりあえずid:nekokakさんのとこはかなり参考にさせてもらいながら、いろいろ試し中です。(まだ新しいWeb+DBは見てませんすいません) そんで、表題の件なんですが。 http://d.hatena.ne.jp/nekokak/20061227/1167210571 結局、ResultSetクラスにメソッド生やしちゃうと、全部のSchema(テーブル)でそのメソッドが共有されちゃうことになって、あんまりうれしくないケースもあったりすると思うんですが。。。そんなことないですか?そうですか。 てなわけで、ワタクシとしては 案2:自分でResultSetのクラスを作成する。 かなあ、という結論にいたりました。 んで、テーブルごとに MyApp::Schema::User に対して MyApp::Schema::User::R

    DBICのRの件 - Hack Forever改めhi-rocksのはてなダイアリー
  • DBIx::Class + Catalyst::View::JSON - ヒルズで働く@robarioの技ログ

    InflateColumnを使っているときに問題があったため、修正版を新しいエントリに起こしました。 修正版:DBIx::Class + Catalyst::View::JSON(2) - ヒルズで働く@robarioの技ログ 昔書いたメモが出てきたので転載。 DBIC::ResultSet#findやDBIC::ResultSet#searchしたものをそのままJSONにしたいじゃないですか。 でもCatalyst::View::JSONにそのまま渡すとCatalystが落ちるんですよ。 なので適当に展開してくれるサブルーチンを作って使っています。 Catalyst::View::JSON以外でも使うので、アプリケーションクラスに置いています。 ### lib/MyApp.pm sub expand_dbic { my ( $c, $obj ) = @_; if ( !Scalar::U

    DBIx::Class + Catalyst::View::JSON - ヒルズで働く@robarioの技ログ
  • DBIx::Class::ResultSet

    mst: Matt S Trout (project founder - original idea, architecture and implementation) castaway: Jess Robinson (lions share of the reference documentation and manuals) abraxxa: Alexander Hartmaier acca: Alexander Kuznetsov acme: Leon Brocard aherzog: Adam Herzog Alexander Keusch alexrj: Alessandro Ranellucci alnewkirk: Al Newkirk Altreus: Alastair McGowan-Douglas amiri: Amiri Barksdale amoore: Andre

    DBIx::Class::ResultSet
  • 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; こうしてやればイテレータがリセットされます。 この場合、2個のwhileのところでそ

    DBICでの簡単キャッシング - Hatena::Diary::Neko::kak 500 Internal Server Error
  • randomなレコードを指定数取得する - 日向夏特殊応援部隊

    d:id:jojo_a_gogogo:20061220:1166612945 (元ネタ) d:id:nekokak:20061222:1166748742 (添削版w) と言う訳でid:nekokakさんの方が確かにシンプルですな。 SELECT me.id, me.name FROM member me ORDER BY RAND() LIMIT 3; ってPostgreSQLでも動くのだろうか。 手元に無いのでいまいち分からん。 DBICのコードはどういう訳か復活の呪文に見えるのは僕だけですか?orz...

    randomなレコードを指定数取得する - 日向夏特殊応援部隊
  • Elementary, ... 最近のコネタ

    この前の仕事からTipsをダンプ... Catalyst x Lighttod の時、Catalyst は 5.7004 以上必須 Shibuya.pm の typester さんの話で感化されたのもあって採用した Lighty、イイ。シンプルに言われたことだけをこなしてくれる感じ。 で、Catalyst を Lighty で動かすときは Catalyst 5.7004 以上が必須なんすね。でないと、SCRIPT_NAME などの環境変数のバグから、http://example.com/foo/ と http://example.com/foo のように最後にスラッシュが付く付かないで実行されるアクションが変わってしまう。なので今後はアプリケーションクラスにすぐ use Catalyst::Runtime '5.7004'; と書くことにした。 Lighty、UploadProgressは

  • CLON - 2006/11/21 - DBIx::Class vs mysql vs UTF-8

    DBIx::Class vs mysql vs UTF-8 それ、0.7以降(多分)ならconnectionやconnect上書きしなくてもこうかけるよ。 __PACKAGE__->connection( 'dbi:mysql:foo', 'root', { on_connect_do => ['SET NAMES utf8'], }, );

  • 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"; } } こんな荒業もできます

    DBICでネストしたループ - Hatena::Diary::Neko::kak 500 Internal Server Error
  • 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

    add_unique_constraintで行かない - Hatena::Diary::Neko::kak 500 Internal Server Error
  • スカラりふぁれる - Hatena::Diary::Neko::kak 500 Internal Server Error

    格言「困ったら、Scalarりふぁれる」。 です。はい。 日もDBICネタですが、DBICのRで困ったらスカラーリファレンスです。はい。 $self->model('User')->search( { 'me.created_on' => \'IS NULL', } )->first; created_onはDATETIME型とします。 こんな感じで実行すると、 SELECT me.created_on, me.rid, me.id FROM user me WHERE ( me.created_on IS NULL ) こんなSQLが実行されます。 さらに、 $self->model('User')->search( { 'me.created_on' => \' > NOW()', } )->first; こんな感じで実行すると SELECT me.created_on, me.ri

    スカラりふぁれる - Hatena::Diary::Neko::kak 500 Internal Server Error