欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
I’ve been working on revamping the Active Record query interface for the last few weeks ( while taking some time off in India from consulting work, before joining 37signals ), building on top of Emilio’s GSOC project of integrating ARel and ActiveRecord. So here’s an overview of how things are going to work in Rails 3. What’s going to be deprecated in Rails 3.1 ? These deprecations will be effecti
● [Rails] with_scope (ActiveRecord) ActiveRecord::Base.with_scope(method_scoping = {}) {|| ...} with_scope はテーブル操作の範囲を限定するクラスメソッドです。指定されたブロックを実行する際、xxx_by_sql 以外のテーブル操作用のクラスメソッド全てが引数で指定された制限(影響)を受けます(※1)。 以下のような場面で効果を発揮します。 共通の値を持つ複数アイテムを簡単に初期化したい。 find(params[:id]) で取得したデータが不正アクセスかどうかの検証が面倒だ。 かと言って、find 時に :conditions 指定するのも面倒だ。 さらに、それをCRUD毎に指定するなんて気が遠くなる。 ※1:レシーバと同じクラスのみ影響を受けます。 ● スコープ指定 スコープの種類
最近は、自分用にRailsの挙動を拡張するために書いた lib/xxxx_ext.rbが増えてきました。 こういったファイルはconfig/initializer/の直下に 置いても良いのですが、ON/OFFを切り替えやすいので、 config/initializer/libs.rbの中から、require "xxxx_ext" を呼ぶようにしています。 さて、今回はActiveRecordをさらに便利に使うために、 僕が行っている拡張を紹介します。 lib/active_record_ext.rb 1 module ActiveRecord 2 class Base 3 def self.[](arg, *args) 4 case arg 5 when Range 6 find arg.to_a 7 when Hash 8 find :all, arg 9 when :
ActiveRecord 向けのビューヘルパーメソッドを使いたい 複雑な検索条件などをフォーム上で表現するとき、ページのリロード時の値の保存や値のパースに便利なように、モデルクラスを利用したいときがあるかもしれない。たとえば、 <%= select 'search_cond', 'demographic', [["10歳未満", 1], ["10代", 2], ["20代", 3], ["30歳以上", 4]] %> などとしたいのである。問題は当然ながら search_conds などというテーブルがデータベースに存在しないことである。text_field や select など *_tag というポストフィックスが付かないビューヘルパメソッドはすべて、ActiveRecord::Base オブジェクトの存在を前提としている。どうしたらいいだろうか? ActiveRecord をどう騙す
Rails ではデータベースのテーブルを作成するのに、db/migrate/ にマイグレーション用のファイル # $RAILS_ROOT/db/migrate/001_create_entries.rb class CreateEntries < ActiveRecord::Migration def self.up create_table :entries do |t| t.column :title, :string t.column :body, :text end end def self.down drop_table :entries end end を作ったあと、 % rake db:migrateとすることで、"entries" という名前のテーブルがデータベースに作成される。この内部動作をしつこく追いかけてみる。 rake db:migrate まずは rake コマン
Rails で違和感を覚えるのは、モデルにだけアプリケーション層に基底クラスが用意されていない所。違和感の正体はMVCの対称性だけではなく、実際に不便なのだ。ここで言う「アプリケーション層の基底クラス」とは、フレームワークレベルに直接定義するのは気がひけるけど、現在のアプリケーションで自分が定義するクラス全体には影響を与えたいような定義を行うクラスの意。例えば、セッション情報であれば、フレームワークレベルでなく、ApplicationControllerに定義するのが自然だし、現在の ActionPack でもそういう実装になっている。同じことがビュー(ヘルパ)においても可能だが、モデルだけはなぜか ActiveRecord::Base を直接継承しており、これが不便な局面が多々ある。 ApplicationModel 具体的には、既存のNKSKプロジェクトのモデル(クラス群)を別のプロジ
ARの実装とRuby処理系のTimeに関する実装でハマる - Lazy Technology にも書いたけど、ARはDBMSのカラム情報に基づいて、格納された値を自動的にキャスト(変換)する。 ar = AR.new ar.id = "hoge" => "hoge" ar.id => 0 キャストするのは格納時ではなく出力時。 オリジナルの値が欲しい場合はカラム名_before_type_castメソッドを呼ぶ。 a.id_before_type_cast => "hoge" キャストのロジックを実装しているのはColumn#type_castメソッド。以下に定義されている。 activerecord\lib\active_record\connection_adapters\abstract\schema_definitions.rb # Casts value (which is a
ActiveRecordの==はどう動くのか気になったので調べてみた。 例えばSNSで日記にユーザからコメントがついた場合、新着に表示する時にはまず日記を書いたユーザとコメントを書いたユーザが別かどうかを判定しなきゃいけない。 早速ソースを読む。 def ==(comparison_object) comparison_object.equal?(self) || (comparison_object.instance_of?(self.class) && comparison_object.id == id && !comparison_object.new_record?) end つまり、 オブジェクトIDが同じ場合はtrue idが一緒ならtrue、ただし新規レコードはfalse と言う事。 例 #IDが一緒ならTrue user1 = User.find(1) user2 = U
コールグラフ HasManyAssociation の詳細にすすむ前に、青木峰郎氏を見習ってここまでの調査結果をコールグラフにまとめてみよう。コールグラフとはメソッドの呼び出し関係をグラフに表したものだ。詳しくは、RHG 第4章「クラスとモジュール」を見てほしい。 ActiveRecord::Associations::ClassMethods#has_many (associations.rb) ActiveRecord::Associations::ClassMethods#create_has_many_reflection (associations.rb) ActiveRecord::Reflection::ClassMethods#create_reflection(reflection.rb) ActiveRecord::Associations::ClassMethods#
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く