気がつけば一ヶ月以上更新してなかった。お久しぶりです。 表記の通り、Otogiri::Plugin::TableInfo 0.02 をリリースしました。 Otogiri::Plugin::TableInfo というのは、このへんに細かい話を書いておりますが、 MySQL でいうところの、show tables とか show create table っぽいデータ(つまりテーブルの一覧と、テーブル定義)を見れる感じの物体です。 今回のリリースでは、show_create_viewというメソッドを足しています。名前の通り、View の定義が見れる感じになっております。 CPAN はこちら -> Otogiri::Plugin::TableInfo Enjoy!
ちょいちょいこの blog に書いてますが、最近 Otogiri::Plugin::TableInfoっていう物体を 書きました。 こんな感じで使える物体です。 use Otogiri::Plugin::TableInfo; my $db = Otogiri->new( connect_info => [ ... ] ); $db->load_plugin('TableInfo'); my @table_names = $db->show_tables(); # => DB 上にあるテーブル名一覧が返る my @filtered_table_name = $db->show_tables(qr/^user/); # => 「user」で始まるテーブル名一覧が返る my $create_table_ddl = $db->desc('user'); # => user テーブルの CREATE
おはよーおはよー。今日はエイプリルフールですが、これは真面目な(?)話です。 REPLでORMを使えるようにすると、めっちゃ便利だ、という話の続き。 とりあえず僕がほしかった環境が大体できたので、公開してみようと思う。 やりたかった事は Reply の設定ファイルをコピペするのが良く無いので、1つにしたい(プラグインを追加するたびに全部書き換えとか嫌) せっかく Reply::Plugin::Otogiri あるし使ってみるか の2点です。 Reply::Plugin::Otogiri について 前回紹介した、 ｢Reply::Plugin::Otogiri｣を書いた ですが、R::P::Otogiri はバージョンアップしてちょっと中身が変わったので内容が古くなっています。SYNOPSIS とか見ると分かるのですが、 新しいバージョンでは、設定ファイルを指定できてそこに DB の接続情報
表記のものをリリースしました。 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 オプション つければ出来るけどつけてないから出来ない
名前の通り、Teng::Lite みたいなモジュールを作った。 Teng::Lite でも良かったけど、なんとなくそれっぽい名前が思い浮かんだのでそれにした。 ORM というよりはやや重めのDBIラッパーかもしれない。 Coteng-0.07 - Lightweight Teng - metacpan.org - Perl programming language y-uuki/Coteng · GitHub 早速、会社で作ってるサーバ管理アプリケーションのTengをCotengに置き換えてみた。 サーバ管理アプリケーションの話はこっち。YAPC::Asia 2013ではてなのサーバ管理ツールの話のはなしをしました - ゆううきブログ 背景 普段Perlの ORM として、Teng にお世話になっている。 ただ、最近採用しているフレームワークとの相性が悪くて、そんなに使わない機能があったり
ハロー。今日はクリスマスイブだ。今日は僕からみんなに素敵なプレゼントをお届けしようと思う。 ... ... ... ふぅ。こんな感じで書こうと思ったけど、このキャラ無理だわ。普通に書きます。 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
https://metacpan.org/release/Teng-Plugin-RowObjectCreationSwitcher @tsucchi さんに上げてもらったのでその話。 追記 注意 tokuhiromに意見をもらって0.02でインターフェースが変わりました。 temporary_suppress_row_objects_guard( 1 / 0 ) を新設 (dis|en)able_row_object を廃止 ガードオブジェクト受け取らないとエラーになるように 「こういう$tengみたいなグローバルなオブジェクトの内部を一時的に変えるみたいなのはやらないほうがいいですね！」 と、tokuhiromに言われており、実際そうなので、やるなら自己責任で気をつけて使いましょう。 言われてみると、$teng->suppress_row_objectsがそもそもrwなのが怖い感じがし
https://metacpan.org/module/SQL::Translator::Producer::Teng TengのSchemaは手で書くのがタルいので、Teng::Schema::DumperなりTeng::Schema::Loaderなりを使ってごにょったりしていたのですが、無理やりだし、自動生成すればいいよねとは思っていたので、書きました。 Kyoto.pmでも先日のYAPC::Asiaでも「SQL::Translator::Producer::Tengみたいなのがあればいいかもしれないけど特に不便を感じてないからやってない」とか言っていたのですが、書いてみたら案外サクッとかけたので、CPANizeした次第。 以下の様なSQLファイルがあったとして、 CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT
ユーザーからのPOST等された入力値の妥当性をチェックする Validation をどこでやるか問題が個人的にありまして〜、DBを使わないケースならばいわゆるFomrValidator::*を使ってControllerでやればいいのですが、Modelを経由するようなアプリだとControllerだけじゃ不安よねぇ〜、Modelだけ使う時もあるし、Model単体のテストで再現出来ないよね〜なんて思ってます。で、実際の実装をControllerではFormValidator::Lite、Modelの一部にData::Validatorを使っているのですが、なんかコレも効率悪い感じしてたんで、ちょいと実験的に理想の一つを実装してみました。 こんな条件です。 エラーメッセージを簡単に設定したいのでValidationモジュールにはFormValidator::Liteを使う 色々錯誤していたらOR
December 07, 201208:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か タイムラインで「SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？」ってのを見かけて居ても立ってもいられなくなったので、既出を承知で反論しておきたい。 スライドだけから話の内容を推測すると、 -- 販売成績上位10個を抽出 select * from sales where deleted = false order by amount desc limit 10 といったSQLを Sales.active().top(10).all() のように、細かく分解した部品を組み合わせて表現できた方が便利だし構造的でしょ？という話のようだ。 これは確かに一見美しいのだが、これこそが「敷居を下げすぎて、dbの性質を分かってない人まで気軽にSQLをいじるようになった結
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
