ActiveRecord@ActionController で scoped_access をいろいろな書式で - Milly のメモ
ActiveRecordを詳しく「優しいRailsの育て方」 より。 もっとシンプルにできるけど。 つい機能追加やら汎用化やらをしてしまう。 Rails 2.1.0 で動作確認。 コメントいただいたので scoped_access_filter.rb を修正しました。 使い方 基本。 class MailController < ApplicationController scoped_access Mail, :mine def mine unless user.admin? { :find => {:conditions => ["owner = ?", user]}, :create => {:owner => user } } end end def show @mail = Mail.find(params[:id]) end end 複数のモデルを対象とする。 scoped_a
ActiveRecord::Base#with_scopeとscoped_access - タナカイチロウの日記
ARのfindをある条件で絞っておきたい場合。with_scopeが使える。 Rails2.1以降？にはnamed_scopeというのもあるらしいけど、今回はRails1.2で。 例えばARの論理削除プラグイン、acts_as_paranoidではdeleted_atに削除フラグを立てる。通常のfindでは削除フラグが立ってるレコードは読まないようにAliasされており、あえて削除レコードをfindしたいときはfind_with_deleted（＝オリジナルのfind）を呼べばいい。など。 acts_as_paranoidのように、モデル側で常に条件を絞っておく場合、 たとえばsakuraカラムがNULLじゃないレコードしかfindしないようにするには、 縛りたいModelの中で、 class << self def find_with_sakura(*args) with_scope(:
[Rails] scoped_access / with_scope - ヽ( ・∀・)ノくまくまー(2006-08-16)
● [Rails] scoped_access / with_scope http://capsctrl.que.jp/kdmsnr/diary/20060816.html#p02 へのツッコミが失敗したのでここに書きます。 えっと、必須かどうかは置いといて、"authorize?" と "method_scoping" のどちらで頑張るか、だけの違いにも見えるんですが、どうなんでしょ？scoped_access も、コントローラで行う処理を共通化する事を目的としています。その処理内容は親コントローラなりモジュールで定義して、各利用者用のコントローラで権限(いわゆるロール)を定義する感じです。 ● テーブル定義 例えば、scoped_access がピッタリはまる例として、色んな企業のユーザがログインするポータルサイトを考えます。各ユーザが「メモ」を書けるとして、そのテーブル定義はこんな感
ヽ( ・∀・)ノくまくまー(2006-07-04)
● [Rails] ScopedAccess ScopedAccess プラグインを更新しました。実は今までは production モードでは正しく動かなかったのですが、今回の修正で使えるようになったはずです。 [修正点] dispatcher でリクエスト毎に AR.scoped_methods をクリア Filter#before で条件をキャッシュしてた不具合を修正 (thanks to Nikhil) method_scoping 中の MethodScoping を ClassScoping に自動変換 ※ 1,2 は production への対応です。 [svn] http://wota.jp/svn/rails/plugins/branches/stable/scoped_access [使い方] コードはいつもと一緒 class BlogController < App
ヽ( ・∀・)ノくまくまー(2006-01-05)
● [Rails] with_scope (ActiveRecord) ActiveRecord::Base.with_scope(method_scoping = {}) {|| ...} with_scope はテーブル操作の範囲を限定するクラスメソッドです。指定されたブロックを実行する際、xxx_by_sql 以外のテーブル操作用のクラスメソッド全てが引数で指定された制限(影響)を受けます(※1)。 以下のような場面で効果を発揮します。 共通の値を持つ複数アイテムを簡単に初期化したい。 find(params[:id]) で取得したデータが不正アクセスかどうかの検証が面倒だ。 かと言って、find 時に :conditions 指定するのも面倒だ。 さらに、それをCRUD毎に指定するなんて気が遠くなる。 ※1：レシーバと同じクラスのみ影響を受けます。 ● スコープ指定 スコープの種類
includeの注意点。(eager loading) - はらぐろブログラマン
includeの挙動(Rails2.1.x) users = User.find(:all, :include=>"company") users.company # SQLは実行されない User.findで実行されるSQL(実際とは違うがだいたいこんな感じ) select users.* from users select companies.* from companies 2回SQLが投げられる。 以前はLEFT OUTER JOINが使われていたらしい。 with_scopeやScopedAccessFilterとか使ってるとincludeしたものが別クエリーで実行される方が都合が良かったりする。 以下で説明するがJOINされて1回のSQLになった場合、include対象のテーブルにはwith_scopeの条件が付加されない。 conditionsを付けたときの挙動 以下のように
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20060816.html