Rails - Nov 2006 - So how can I rewrite my app without using with_scope?

So, I hear that with_scope is going to be deprecated.

Which is a bit of a shame, given the stuff I''ve been writing recently.

I have a CMS with multiple clients.  A ''client'' is essentially
a
company, with multiple users.   Content on the site belongs to a client
- content could be messages, images, schedules, etc etc.  People
belonging to one client should not be able to see content created by
people from another client.

I''ve wrapped this all up very nicely into a controller method, looking
something like

class SchedulerController < ApplicationController
  client_filter_on :events, :compositions

  ...

end


which uses some with_scope magic to ensure that any Event or
Composition objects that are created or found within that controller
have a client id matching the currently logged in user.


According to DHH -
http://www.mail-archive.com/rubyonrails-core-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org/msg00579.html
- with_scope is going to be deprecated.  So how do I accomplish this
without with_scope?  Add conditions to every single find & create
method across my entire site?  That doesn''t sound too clever.

Basecamp must have some sort of similar set-up.  How are the 37signals
team preventing one company seeing another company''s secret messages,
without having to remember to filter every query?

Jon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jon wrote:
> So, I hear that with_scope is going to be deprecated.
>
> Which is a bit of a shame, given the stuff I''ve been writing
recently.
>
> I have a CMS with multiple clients.  A ''client'' is
essentially a
> company, with multiple users.   Content on the site belongs to a client
> - content could be messages, images, schedules, etc etc.  People
> belonging to one client should not be able to see content created by
> people from another client.
>
> I''ve wrapped this all up very nicely into a controller method,
looking
> something like
>
> class SchedulerController < ApplicationController
>   client_filter_on :events, :compositions
>
>   ...
>
> end
>
>
> which uses some with_scope magic to ensure that any Event or
> Composition objects that are created or found within that controller
> have a client id matching the currently logged in user.
>
>
> According to DHH -
>
http://www.mail-archive.com/rubyonrails-core-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org/msg00579.html
> - with_scope is going to be deprecated.  So how do I accomplish this
> without with_scope?  Add conditions to every single find & create
> method across my entire site?  That doesn''t sound too clever.
>
> Basecamp must have some sort of similar set-up.  How are the 37signals
> team preventing one company seeing another company''s secret
messages,
> without having to remember to filter every query?
>
> Jon
>   
Use associations instead. They will do what you want.

Example:
client.events.find :all
client.events.create ...


Jack

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Associations first instantiate all of the objects.  Which is not good
if your client has 1000 events, and you only want to find some.

But I think the answer is that with_scope used by AR will *not* be
deprecated, so you can:
def self.find_for_client(*params)
  with_scope(...) { find(*params }
end


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 11/1/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Associations first instantiate all of the objects.  Which is not good
> if your client has 1000 events, and you only want to find some.

Not true: crack open ./script/console, tail -f log/development.log in
another terminal, and watch the queries as you work with your associations.
Most methods which ''ought to'' be a single query really are.

But I think the answer is that with_scope used by AR will *not*
be
> deprecated, so you can:
> def self.find_for_client(*params)
>   with_scope(...) { find(*params }
> end

Code smell.

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jeremy Kemper wrote:
> On 11/1/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Associations first instantiate all of the objects.  Which is not good
> > if your client has 1000 events, and you only want to find some.
>
>
> Not true: crack open ./script/console, tail -f log/development.log in
> another terminal, and watch the queries as you work with your associations.
> Most methods which ''ought to'' be a single query really
are.
Note that I didn''t say "use 1000 queries" but rather
"instantiate 1000
objects," which, indeed, AR *will* do.  This can be a huge performance
hit.  Again, it all depends on the app.
> But I think the answer is that with_scope used by AR will *not* be
> > deprecated, so you can:
> > def self.find_for_client(*params)
> >   with_scope(...) { find(*params }
> > end
>
>
> Code smell.
Pray tell what you find objectionable?
BTW, I should have written: def self.find_for_client(client, *params)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Yet another syntax which may be the best:

def self.scoped_to_client(client, meth, *params)
  with_scope(...) { send(meth, *params) }
end

Usage:
Event.scoped_to_client(client, :find, :first, ...)
Event.scoped_to_client(client, :find_by_sql, "...")


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 11/2/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Jeremy Kemper wrote:
> > On 11/1/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > Associations first instantiate all of the objects.  Which is not
good
> > > if your client has 1000 events, and you only want to find some.
> >
> > Not true: crack open ./script/console, tail -f log/development.log in
> > another terminal, and watch the queries as you work with your
> associations.
> > Most methods which ''ought to'' be a single query
really are.
>
> Note that I didn''t say "use 1000 queries" but rather
"instantiate 1000
> objects," which, indeed, AR *will* do.  This can be a huge performance
> hit.  Again, it all depends on the app.

No, it won''t.  client.events is a proxy object that loads itself only
if
needed.  client.events.find(:first) does not instantiate all 1000 events
then return just the first.

> But I think the answer is that with_scope used by AR will *not* be
> > > deprecated, so you can:
> > > def self.find_for_client(*params)
> > >   with_scope(...) { find(*params }
> > > end
> >
> >
> > Code smell.
> Pray tell what you find objectionable?
> BTW, I should have written: def self.find_for_client(client, *params)

Associations already represent this relation cleanly and understandably.

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 11/2/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Yet another syntax which may be the best:
>
> def self.scoped_to_client(client, meth, *params)
>   with_scope(...) { send(meth, *params) }
> end
>
> Usage:
> Event.scoped_to_client(client, :find, :first, ...)
> Event.scoped_to_client(client, :find_by_sql, "...")

*head explodes*

;)
jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Another very important use of scoping is to eliminate certain types of
records.

For instance:
* Forum - some comments may be marked as "private" - visible by some
but not others.
* Planner - some events marked as "minor" - not shown unless asked
for.
* Financial - some transactions marked as "voided" - recorded but not
(normally) shown.

There''s no way to handle these on the database side using associations.
 Of course, you can always just retreive all of the objects and then
filter with Enumerable#select, but that won''t work for large datasets.

Scoping is the right way to handle these.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 11/2/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Another very important use of scoping is to eliminate certain types of
> records.
>
> For instance:
> * Forum - some comments may be marked as "private" - visible by
some
> but not others.
> * Planner - some events marked as "minor" - not shown unless
asked for.
> * Financial - some transactions marked as "voided" - recorded but
not
> (normally) shown.
>
> There''s no way to handle these on the database side using
associations.
> Of course, you can always just retreive all of the objects and then
> filter with Enumerable#select, but that won''t work for large
datasets.
>
> Scoping is the right way to handle these.

Scoping is attractive when you''re no longer dealing with a
foreign-key-based
relation.  This is rare.

In nearly every case I''ve seen, it''s been used unnecessarily.
The has_many
:conditions option satisfies the scenarios above, for example.

I encourage you to formulate usable abstractions for non-fk relations.
That''s how has_many and friends came to life (foreign key scope on
another
class), after all.

A useless mess of code:
  Event.with_scope(:find => { :conditions => [''client_id =
?'', client.id] })
{ Event.find(:all) }

Meaningfully abstracted:
  client.events

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jeremy:

I''ve got a question about using with_scope for a single table. For  
example, I''ve got a table:

orders
---------
id
amount
warehouse
shipping_method
closed_at

I like the idea of using with_scope to encapsulate some business  
logic about my model. I might create a method to find orders from a  
local warehouse:

def self.local_scope
   with_scope(:find => {:conditions => "warehouse = ''PARK
PLACE'' OR
warehouse = ''BOARDWALK''"}) do
     yield
   end
end

And a method to find Fedex shipments:

def self.fedex_scope
   with_scope(:find => {:conditions => "shipping_method =
''FEDEX''}) do
     yield
   end
end

So, if I needed a method to find orders that are local and shipped  
via Fedex, I could do this:

def self.find_by_local_and_fedex(options = {})
   local_scope do
     fedex_scope do
       self.find(:all, options)
     end
   end
end

This lets me easily write queries such as:

Order.find_by_local_and_fedex(:conditions => {''closed_at =
yesterday''})
Order.find_by_local_and_fedex(:conditions => {''amount >
999'', :order
=> ''amount DESC''})

I know this might seem like an overly simple example, but I''m  
avoiding repeating :conditions clauses for each combination of  
business logic.

Is this a valid use for with_scope, or is there a better way?

Thanks,

-Anthony

On Nov 2, 2006, at 5:50 PM, Jeremy Kemper wrote:
> On 11/2/06, S. Robert James
<srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Another very important use of scoping is to eliminate certain types of
> records.
>
> For instance:
> * Forum - some comments may be marked as "private" - visible by
some
> but not others.
> * Planner - some events marked as "minor" - not shown unless
asked
> for.
> * Financial - some transactions marked as "voided" - recorded but
not
> (normally) shown.
>
> There''s no way to handle these on the database side using  
> associations.
> Of course, you can always just retreive all of the objects and then
> filter with Enumerable#select, but that won''t work for large
datasets.
>
> Scoping is the right way to handle these.
>
> Scoping is attractive when you''re no longer dealing with a
foreign-
> key-based relation.  This is rare.
>
> In nearly every case I''ve seen, it''s been used
unnecessarily. The
> has_many :conditions option satisfies the scenarios above, for  
> example.
>
> I encourage you to formulate usable abstractions for non-fk  
> relations. That''s how has_many and friends came to life (foreign  
> key scope on another class), after all.
>
> A useless mess of code:
>   Event.with_scope(:find => { :conditions => [''client_id =
?'',
> client.id] }) { Event.find(:all) }
>
> Meaningfully abstracted:
>   client.events
>
> jeremy
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 11/2/06, Anthony Carlos
<anthony-icZdIMMiY0Opv2MiSiIzJgC/G2K4zDHf@public.gmane.org>
wrote:
>
> Jeremy:
> I''ve got a question about using with_scope for a single table. For
> example, I''ve got a table:
>
> orders
> ---------
> id
> amount
> warehouse
> shipping_method
> closed_at
>
> I like the idea of using with_scope to encapsulate some business logic
> about my model. I might create a method to find orders from a local
> warehouse:
>
> def self.local_scope
>   with_scope(:find => {:conditions => "warehouse =
''PARK PLACE'' OR
> warehouse = ''BOARDWALK''"}) do
>     yield
>   end
> end
>
> And a method to find Fedex shipments:
>
> def self.fedex_scope
>   with_scope(:find => {:conditions => "shipping_method =
''FEDEX''}) do
>     yield
>   end
> end
>
> So, if I needed a method to find orders that are local and shipped via
> Fedex, I could do this:
>
> def self.find_by_local_and_fedex(options = {})
>   local_scope do
>     fedex_scope do
>       self.find(:all, options)
>     end
>   end
> end
>
> This lets me easily write queries such as:
>
> Order.find_by_local_and_fedex(:conditions => {''closed_at =
yesterday''})
> Order.find_by_local_and_fedex(:conditions => {''amount >
999'', :order =>
> ''amount DESC''})
>
> I know this might seem like an overly simple example, but I''m
avoiding
> repeating :conditions clauses for each combination of business logic.
>
> Is this a valid use for with_scope, or is there a better way?
>
Anthony, I think this use of with_scope is just fine. It reflects the lack
of a convenient way to combine conditions.

What do you think of

  Local = "warehouse in (''PARK PLACE'',
''BOARDWALK'')"
  Fedex = "shipping_method = ''FEDEX''"

  def self.find_all_by_local_and_fedex(options = {})
    find :all, merge_conditions(options, Local, Fedex)
  end

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jeremy:

That''s a pretty interesting solution. I guess merge_conditions would  
be trivial to write. Maybe if with_scope goes away, they''ll include  
merge_conditions.

Just thinking out loud...I think with_scope queries are compatible  
with dynamic finders:

def self.find_fedex_by_warehouse(warehouse)
   fedex_scope do
     self.find_by_warehouse(warehouse)
   end
end

Can you write it in your solution as the following?

def self.find_fedex_by_warehouse(warehouse)
   self.find_by_warehouse(warehouse, :conditions => Fedex)
end

(I think that works!)

I might be able to get used to it. I can''t see any downside to it  
right now. And, I guess that if Local or Fedex had some kind of  
dynamic component would you really write a *_scope for it? Maybe, but  
there''s too many possibilities.

It''s a viable alternative-- especially if with_scope disappears!   
What do you think?

Thanks,

-Anthony



On Nov 2, 2006, at 8:40 PM, Jeremy Kemper wrote:
>
> Anthony, I think this use of with_scope is just fine. It reflects  
> the lack of a convenient way to combine conditions.
>
> What do you think of
>
>   Local = "warehouse in (''PARK PLACE'',
''BOARDWALK'')"
>   Fedex = "shipping_method = ''FEDEX''"
>
>   def self.find_all_by_local_and_fedex(options = {})
>     find :all, merge_conditions(options, Local, Fedex)
>   end
>
> jeremy
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Where is the authoritative source of stuff you can do with the AJAX
libraries included with ROR?
http://demo.script.aculo.us/ajax/sortable_elements 
 
----------~----~----~----~------~----~------~--~---


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Nicholas,

   > Where is the authoritative source of stuff you can do with the AJAX
   > libraries included with ROR?
   > http://demo.script.aculo.us/ajax/sortable_elements

Look at
   http://demo.script.aculo.us/

for demos and code samples.

Alain

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Two questions for you Jeremy (or anyone else who won''t miss
with_scope):

- how would you implement the act_as_paranoid plugin omitting
with_scope?  We''ve several similar, non-FK usages of with_scope in our
app that we modelled after act_as_paranoid (e.g. filtering items
published_at the last X days)

- is Rails adding merge_conditions to replace with_scope?

Thanks.

> >
> > def self.local_scope
> >   with_scope(:find => {:conditions => "warehouse =
''PARK PLACE'' OR
> > warehouse = ''BOARDWALK''"}) do
> >     yield
> >   end
> > end
> >
>
>   Local = "warehouse in (''PARK PLACE'',
''BOARDWALK'')"
>   Fedex = "shipping_method = ''FEDEX''"
>
>   def self.find_all_by_local_and_fedex(options = {})
>     find :all, merge_conditions(options, Local, Fedex)
>   end
> 
> jeremy
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Here''s what I did as a sort of merge_conditions.  It''s a find
that takes an
array of hashes containing conditions - 
[{:name_field => ''foo''}, {:whatever =>
''bar''}, {:order => ''name_field'' }].
At the time I needed something to support user searches on multiple fields.
Seemed less than elegant, but functional.

 - James Moore

class ActiveRecord::Base
  def self.find_with_multiple_conditions(conditions, order =
'''')
    conditions = conditions.to_a
    if conditions.blank?
      order_hash = order.blank? ? {} : {:order => order}
      return find(:all, order_hash)
    else
      k, v = conditions.first
      case k
      when :include, :limit then sql_conditions = {k => v}
      when :order then order = v
      else
        sql_conditions = {:conditions => ["#{k} = ?", v]}
      end
      # if this pass didn''t add any conditions (:order, for example)
      # just continue processing the condition list
      if sql_conditions.blank?
        return find_with_multiple_conditions(conditions.slice(1,
conditions.length), order)
      else
        scope_conditions = {:find => sql_conditions}
        with_scope(scope_conditions) do
          return find_with_multiple_conditions(conditions.slice(1,
conditions.length), order)
        end
      end
    end
  end
end

> -----Original Message-----
> From: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:rubyonrails-
> talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] On Behalf Of Brittain
> Sent: Friday, November 03, 2006 8:55 AM
> To: Ruby on Rails: Talk
> Subject: [Rails] Re: So how can I rewrite my app without using with_scope?
> 
> 
> Two questions for you Jeremy (or anyone else who won''t miss
> with_scope):
> 
> - how would you implement the act_as_paranoid plugin omitting
> with_scope?  We''ve several similar, non-FK usages of with_scope in
our
> app that we modelled after act_as_paranoid (e.g. filtering items
> published_at the last X days)
> 
> - is Rails adding merge_conditions to replace with_scope?
> 
> Thanks.
> 
> 
> > >
> > > def self.local_scope
> > >   with_scope(:find => {:conditions => "warehouse =
''PARK PLACE'' OR
> > > warehouse = ''BOARDWALK''"}) do
> > >     yield
> > >   end
> > > end
> > >
> 
> >
> >   Local = "warehouse in (''PARK PLACE'',
''BOARDWALK'')"
> >   Fedex = "shipping_method = ''FEDEX''"
> >
> >   def self.find_all_by_local_and_fedex(options = {})
> >     find :all, merge_conditions(options, Local, Fedex)
> >   end
> >
> > jeremy
> >
> 
> 
> 
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

>From the referenced message:
> The decision has been rendered as follows: with_scope will go protected
> from Rails 2.0. That means you''ll be able to use with_scope in
your own
> private finders (the only legitimate use I''ve seen), but not in,
say,
> filters.
Where does this say with_scope will be deprecated?


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---