Tengについて
先ほどTengという新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ３年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
django で論理削除を実現してみる - 記憶は削除の方向で
イベント系のデータならともかく、リソース系のデータの論理削除というのは結構需要が多そうな気がするけど、あまり触れられてないのはなんでだろうか？すでに Django Snippets とかにあるような気もするけど、なかなかいいアイデアが浮かんだのでメモしておく。 まずは前提とするモデルから。 class Author(models.Model): name = models.CharField(u'名前', max_length=255) deleted = models.BooleanField(u'論理削除フラグ', default=False) def delete(self): self.deleted = True self.save() class Entry(models.Model): content = models.TextField(u'内容') author = mo
DataMapper での Associations に Hook をからませる - daily dayflower
DataMapper での One-To-Many-Through - daily dayflower の続き。 下記はあくまで説明のためのサンプル((まじめにアプリとしてインプリメントするなら，単に User や Mail モデルに削除フラグ（というか available フィールド？）を用意してそこを操作するだけにすると思う。))。 単純な One-To-Many (belongs_to と has n) の場合 require 'rubygems' require 'dm-core' require 'dm-aggregates' # Collection の count() 等をあとで使うため ### モデルの定義 class User include DataMapper::Resource property :id, Serial property :name, String
DataMapper での One-To-Many-Through - daily dayflower
DataMapper 0.10.1 が対象。 単純な One-To-Many ではなくて、ひとつ間にテーブルをかます One-To-Many-Through のおはなし。 たとえばユーザ・ユーザ間のメールのやりとりをモデルに起こすとして、あるユーザが複数のユーザに同時に同じメッセージを送ることができるとすると、 メールを表すテーブル メールの受信者を表すテーブル をわけることになる（まあメールレコードを受信者数分コピーすれば One-To-Many でもできるけど）。 そんなときの DataMapper の使い方の話（DataMapper を使う (Associations) - KrdLab's blog がとても参考になった）。 モデルの定義 User はユーザを表すモデル Mail はメールを表すモデル Mail::Recipient はそのメールの受信者（へのマッピング）を表すモデ
ramaze-users.jp - DataMapper
sudo gem install datamapper 本体であるdm-coreと、それをサポートするdm-migrations, dm-timestampsなどのライブラリがインストールされる。 require 'rubygems' require 'datamapper' # DB接続 DataMapper.setup(:default, "sqlite3://book-dm.db") # モデルの定義 class Book include DataMapper::Resource property :id, Serial property :title, String property :year, Integer end # スキーマの作成 DataMapper.auto_upgrade! #モデルに合わせてテーブル構造を調整する # データの作成 Book.create(:tit
Casual Perl Talks#1でLTしてきました - Lism.in * blog - nekoya (id:studio-m)
DBIx::Skinnyと仲間たちView more presentations from Ryo Miyake. http://perl-casual.org/2009/10/1127casual-perl-talks1.html を見て10分のLTだと思って資料用意したら5分LTだったよ！ 後から出たタイムテーブルには5分って書いてあるのに、古い案内見て勘違いしてた。タイムテーブルのエントリをブクマしたにも関わらずこのありさまだよ。 5分の発表で55ページだから間違いなく今回最多ページ数は俺の物だと思ったら、id:xaicronが120ページを用意するという暴挙に出たためすっかり霞んでしまった。つーか120ページでしかもデモまで予定してたとか、10分でも無茶だろJK… まぁ何とか5分で最後まで話したわけですが、あと30秒欲しかった。5分ちょうどで終わる計画を立ててもダメですね。4分30
YappoLogs: Data::Model っていう ORM みたいの CPAN にあげたよ
Data::Model っていう ORM みたいの CPAN にあげたよ あざーす。循環参照しすぎるとバターになる。。なんでそんなに人の目を気にするのだろうと、マジレス。 早速ですが Data::Model っていう O/Rマッパー 的な物を CPAN にあげました。 Data::Model http://github.com/yappo/p5-Data-Model/tree/master 元来は MVC モデルで言う所の Model を一括でまかなえるつもりで実装していますが、ロジック処理は普通の Perl のクラスで書いちゃった方が潰しが聞くため、主にストレージを Perl のオブジェクトにマッピングする ORM 的な使い方が主流となっています。 そして、 Data::Model の多くの実装や設計などは Data::ObjectDriver を参考にして開発しました。 他にも後述して
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
DBIx::Skinny - Yappo::タワシ
DBIx::Skinny はとにかくSQLクエリベースでRowオブジェクトが作られますな。 select, insert, update, delete は SQL::Abstract::Limit 使ってる。 組み立てた SQL を DBIx::Skinny::SQLStructure に通してから DBIx::Skinny::Iterator でイテレータ作ってる。 DBIx::MoCo の場合は DBIx::MoCo::List に ARRAY を渡すだけだけど。 Skinny::DBD::* は、いわゆる last_insert_id のためだけに使っている。 MoCo と違って Schema は DBIx::Skinny::Table を継承している。DBIx::Skinnyが全ての要素のroot classにはなってなくてすっきり。 Class::Trigger で inser
ORMを作るために最低限必要な4+1のコンポーネント - Yappo::タワシ
短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yokohama.pm #5でData::ObjectDriverについて発表してきた