おはよーおはよー。今日はエイプリルフールですが、これは真面目な(?)話です。 REPLでORMを使えるようにすると、めっちゃ便利だ、という話の続き。 とりあえず僕がほしかった環境が大体できたので、公開してみようと思う。 やりたかった事は Reply の設定ファイルをコピペするのが良く無いので、1つにしたい(プラグインを追加するたびに全部書き換えとか嫌) せっかく Reply::Plugin::Otogiri あるし使ってみるか の2点です。 Reply::Plugin::Otogiri について 前回紹介した、 「Reply::Plugin::Otogiri」を書いた ですが、R::P::Otogiri はバージョンアップしてちょっと中身が変わったので内容が古くなっています。SYNOPSIS とか見ると分かるのですが、 新しいバージョンでは、設定ファイルを指定できてそこに DB の接続情報
日付的には一昨日(3/20)ですが、Perl Beginners #12に行ってきました。LTしました。 資料はこちら 異常な努力をする前に 世の中には「異常な努力」によって成り立っている凄いモジュールがあること、でも簡単な処理でついうっかり「異常な努力」しちゃう事ってあるよね?気をつけよう、というお話です。以前話した「正解はひとつ!じゃない!!」のコードありバージョンみたいな感じですね。僕の前の papix さんのやつがコードない系だったのでちょうと良かったんじゃないかなー、と勝手に思っています。なお、今回はミルキィホームズ成分は控えめでお送りしました。 Perl Beginners はビギナー向けとはいいますが、色んなレベルの色んなお話が出てきて、しかも気軽な感じですごくいいなぁ、と思います。予定が合えば、また参加したいなー。
表記のものをリリースしました。 Otorigi-0.09 ポスグレ使っている人以外は全然関係ないのですが、PostgreSQL って last_insert_id を取得する際に、 シーケンスの名前を指定しないと取れないんですよ。 で、一方で、MySQL の LAST_INSERT_ID() みたいな振る舞いをする、LASTVAL() って関数もあります。 なので、これ使って便利にしたいなー、と思って改修してみました。 前回書いたように、最近 Otogiri + REPL の環境で DB を触っているのですが、 $db->last_insert_id(undef, undef, undef, { sequence => 'some_table_id_seq' });
多分下記の続きみたいな話。 Otogiri という ORM のご紹介 と Otogiri::Plugin 「SQL アンチパターン」を読んだ FK 貼っているテーブルにテストデータをぶっ込んだり、データを何度か入れ直しするのってめんどくさいですよね? 前職では、(Fixture ではなく、)ファクトリ使ってテストデータをぶっ込む仕組みを作っていたので、FK のあるテーブルの データを入れるのは大変でした。(ゴミデータをちゃんと消さないと、外部キーの不整合でエラーになる)。今はモックでテストしてるので、 テストコードでは困ってませんが、普通にデータ入れ直しするときとか、やっぱメンドクサイんですよ。 で、「SQL で親から順番に消してくれる特殊構文とかあればいいのに」と思ったんですが、そういうの無いんですよね。。。(FK に CASCADE オプション つければ出来るけどつけてないから出来ない
タイトルはちょっと釣りっぽいかも。 たとえば配列に id が10万件位入っていて、コレを使って SQL の DELETE 文を発行してデータをパージしたい、とします。(仮にDELETEとしたけど、SELECT でも UPDATE でも一緒の話。DBの処理じゃなくても多分こういうのある)。 こういうとき、10万件一気に IN で指定すると、多分SQLが長過ぎてエラーになるし、もしエラーにならなくても遅いし、かといって 1件ずつ処理してもやっぱり遅いので、ふつうは何件かまとめて処理します。 仮に1000件毎に処理するとしましょう。 こういうとき、どうするか、というのが今日のお話。どうします? やり方はいくつかあると思うのですが、この場合僕は splice を使います。 my @ids = ... #10万件のidの配列 while ( my @sub_ids = splice(@ids, 0,
ハロー。今日はクリスマスイブだ。今日は僕からみんなに素敵なプレゼントをお届けしようと思う。 ... ... ... ふぅ。こんな感じで書こうと思ったけど、このキャラ無理だわ。普通に書きます。 Otogiriとは Otogiri という ORM(?)があります。これは@ytnobodyさんが作ったやつで、 Synopsis 丸写しするとこんな感じの物体です。 use Otogiri; my $db = Otogiri->new(connect_info => ['dbi:SQLite:...', '', '']); my $row = $db->insert(book => {title => 'mybook1', author => 'me', ...}); print 'Title: '. $row->{title}. "\n"; my @rows = $db->select(book
やりたいこと 'Asia/Tokyo' のようなタイムゾーンを表す文字列を、「+0900」や「32400」(秒=9h)に変換する。 やり方 DateTime を使って変換する(?) use strict; use warnings; use DateTime; my $dt = DateTime->now(); $dt->set_time_zone('Asia/Tokyo'); warn $dt->offset; # => 32400 warn $dt->strftime("%z"); # => +0900
メソッドとか変数の名前って、いつも結構悩みますよね? んで、最近 get_ みたいなメソッド名使いたいなーって思う事があるんですよ。 fetch でも search でも retrieve でもない、「いや、ちょっと引くだけだから get_ で良くね?」って思うんですよね。 正直なところ、 get も set も本来だったら使ってもいいんじゃないかな、と思うんですよ。でも、Java とかがアクセッサメソッドの規約みたいな感じで get/set を使うようにしちゃったせいで、それ以外の局面で get/set を使うと、「なんか違くね?」みたいな感じになったりするんですよね。 と、いう話を某チャットでしていたら、「bring がいいっすよ」みたいな指摘を頂いたので、ここに共有しときます。「get_ 使いたい病」を発症した際は、 「bring」の使用を検討してみると、もしかしたら幸せになれるかも
多分、これの続きみたいな話。。。なのかな。 生SQLを使うロジックをテストする場合、データを突っ込む仕組みを作って SQL を実際に投げるか、DBD::Mock あたりを使うのが普通なのかな、 と思います。 DBD::Mock は凄く良く出来てて、エラー条件なんかも含めて、ほとんどの DBI の振る舞いを偽装できて便利なのですが、割と長大で設定がめんどい 感じするし(使うときは毎回ググってる)、最初に挙げた記事みたいに微妙に機能が足りなかったりして困る事もしばしばあります。 なので、じゃあ Test::Mock::Guard とか、そのへんのスタブ使って偽装作ろうとすると、それはそれで面倒だったりします。「$dbh ってなんだっけ?」(正解は DBI::db)とか、 「$sth って(ry」(DBI::st)とか、「'...is not a DBI handle (has no magic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く