nekokakさんが以前TengとDBIx::Skinnyのベンチマークとってみたでとっていたのですが、1年半以上経っていてその後Tengはバージョンアップを重ねていますので、改めてとってみました。 ベンチマークスクリプトはnekokakさんのものをもとに少し改造してtestもつけたりしました。 結果はこちら。 はやくなってますね :)
nekokakさんが以前TengとDBIx::Skinnyのベンチマークとってみたでとっていたのですが、1年半以上経っていてその後Tengはバージョンアップを重ねていますので、改めてとってみました。 ベンチマークスクリプトはnekokakさんのものをもとに少し改造してtestもつけたりしました。 結果はこちら。 はやくなってますね :)
なんか、いつもイレギュラーなことやってない?ばかなのしぬの? とか思いつつ、データベースの激しい都合上 my $rs = $my_skinny->resultset; # とある $rs さんの旅 ... $rs->add_join('table t' => [ { type => 'inner', table => 'join j', condition => 't.join_key = j.join_key AND t.join_num = j.join_num' } ] ); $sql->as_sql; # => FROM table t JOIN join j ON t.join_key = j.join_key AND t.join_num = j.join_num とか毎回書いていたのですが、いい加減めんどくさくなっtごにょごにょ。。。*1 設計がそもそもぷぎゃーなんじゃないの
http://search.cpan.org/dist/DBI/DBI.pm#clone DBIにcloneメソッドがあることを@nihenさんがみつけました。 #いやーDBIのドキュメントは良く読むと便利メソッドが一杯ありますね TengとかSkinnyではconnect_infoを受け取るだけでなく、 $dbhを受け取って利用する仕組みも提供しているのですが、 そこで一番問題になっていたのはdbへの接続がブチギレた場合のreconnectの問題でした。 connect_infoがある場合は接続情報を自分で持っており、簡単に再接続できるんですが $dbhしかない場合はいままでできないとおもっていました。 DBI的にも接続時につかったpasswordを取るインタフェースがなかった。 なので$dbhを渡された場合は自動reconnectは行わずにエラーで死亡にするようになってたんですが、 D
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
DBIx::Skinnyで簡単に使えるpagerが実装されていない主な理由は、 http://perl-users.jp/articles/advent-calendar/2009/dbix-skinny/19.html とかに書いているんですが、 管理画面にありがちな データを様々な条件で検索するページみたいなのを書くときにはSQLを直書きするのはつらくて、DBICみたいにresultsetを条件によってwhere節を追加するのが楽なこともあります。そういうページに限ってpagingの処理は必要になるけど、ひとつひとつSQLを直接書いてPagerを生成するとかなってくるとなかなかめんどくさいです。 http://d.hatena.ne.jp/nekokak/20090924/1253761408 とかいうのをselectするたびに書いてると、ちょっとごちゃごちゃして見にくいし、結構長くて
先ほどTengという新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ3年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
・DBIx::Skinny::SQLがいけてないのでなおしたい $skinnyのObjectに依存しているのがretrieveメソッドだけなので 若干のインコンパチな変更になるけどなんとかしたいかな。 あとDBIx::Skinny::Accessorを廃止したい。 正直SQL builderとしていけてない。(Data::ObjectDriverからぱくっといてなんだけど) complex_whereとか書きにくすぎる ・AnonRowクラスの廃止 Rowクラス生成を必須とするかどうか。 ・ClassメソッドでDBIx::Skinnyを操作出来るインタフェース 正直インスタンスをつくって操作したほうがよいのでSkinnyとして廃止したい。 後方互換かんがえると結構大変なことなり。 ちなむとヤルにしてもいきなりエラーになるとかはしないのでご安心を。 そしてヤルか
DBIx::Skinnyにはネイティブにpagingをしてくれる便利機能はありません。 (最近ないないばっかり言ってるな) DBICとかだと$rs->pagerみたいにしてData::Pageのオブジェクトを返してくれるんですが、 Data::Pageのオブジェクトを作る際に、内部でcountを発行しています。 pagingするにはSQLにLIMIT/OFFSETをかけてると、思うのでLIMIT/OFFSETを掛けなかった際の トータルな件数を取るためですね。 結構このcountが馬鹿にならないくらい内部で発行されることがあるのでSkinnyではあえてサポートしなかったです。 あと、独自にSQLを書かせる事をお題目にあげているので、 独自に書かれたSQLを内部でごちゃごちゃしてcount発行するとかヤッテラレナイてのもあります。 ただ、アプリを作ってる時にpagingは必須なのでどうすれば
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
(10/07追記)Skinny界のpgsql番長、id:sfujiwaraさんから早速PostgreSQL対応パッチを頂きました。すばらしす DBIx::Skinnyを使うのに、install_table書くのが面倒なので作りました。 nekoya's p5-dbix-skinny-schema-loader at master - GitHub 使い方とかはPodに書いてあるんだけど、改めて日本語で補足も交えて書いておきます。 package MyApp::DB::Schema; use base qw/DBIx::Skinny::Schema::Loader/; __PACKAGE__->load_schema; 1; とか書いておくと、全テーブルのinstall_tableを自動設定します。 この時、DBから情報を読み出すのに、MyApp::DBに書いてあるdsnの設定を取ってくるの
Skinnyの発表資料は http://nekokak.org/presen/yapcasia2009-dbix-skinny/ こちらになります。 ご意見などどしどしおまちしております。 nekokak _at_ gmail _dot_ com で本日の発表の補足をば。 Skinnyの発表の時にも言いましたが、 Skinnyの発表前のYappoさんのData::Modelの発表の中で、 「SkinnyはSQLをパーズして云々だからバグバグぽい部分がありそげ。」 とおっしゃってましたが、現在のSkinnyはSQLのパーズをしておりません。 昔はSQL::Parserでパーズするのを試している事があったのですが、 SQL::Parserが複雑なSQLをパーズできないので捨てました。 - Skinnyでは現在install_utf8_columnsというfunctionでutf8flagの処理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く