ruby on rails named scope implementation

2020-05-29 06:13发布

问题:

From the book Agile Web Development With Rails

class Order < ActiveRecord::Base
   named_scope :last_n_days, lambda { |days| {:conditions =>
      ['updated < ?' , days] } }

   named_scope :checks, :conditions => {:pay_type => :check}
end

The statement

orders = Orders.checks.last_n_days(7)

will result to only one query to the database.

How does rails implement this? I'm new to Ruby and I'm wondering if there's a special construct that allows this to happen.

To be able to chain methods like that, the functions generated by named_scope must be returning themselves or an object than can be scoped further. But how does Ruby know that it is the last function call and that it should query the database now?

I ask this because the statement above actually queries the database and not just returns an SQL statement that results from chaining.

回答1:

There are two tricks (or patterns if you will) employed in the named_scope magic.

Proxy pattern - calling a named scope method on a class or an association always returns an instance of the ActiveRecord::NamedScope::Scope class, not a colleciton of filtered AR objects. This pattern, altough very useful, makes things kind of blurry sometimes, since the proxy objects are ambivalent in their nature.

Lazy loading - thanks to lazy loading (which in this context means - hitting the database only if neccessary) named scopes can be chained up to the point when you need to work with the collection defined by the scopes. Whenever you request the underlying colleciton, all the chained scopes are evaluated and a database query is executed.

One final note: There's one thing to have in mind when playing with named scopes (or with any thing that uses delegation of some kind) in IRB. Everytime you hit Enter, the thing you wrote beforehand is evaluated and the inspect method is called on the returned value. In the case of chained named scopes, although the whole expression is evaluated to a Scope instance, when the IRB calls the inspect method on it, the scopes are evaluated and the database query is fired. This is caused by the fact that the inspect method is by means of delegation propagated through all the scope objects up to the underlying collection.



回答2:

You might want to try this

class Order < ActiveRecord::Base

  class << self
    def last_n_days(n)
      scoped(:conditions => ['updated < ?', days])
    end
    def checks
      scoped(:conditions => {:pay_type => :check})
    end
  end

end

usage is the same

@orders = Order.last_n_days(5)
@orders = Order.checks
@orders = Order.checks.last_n_days(5)

This still does all the lazy loading you love. That is, it won't make a query until you attempt to access the records. Bonus: Rails 3 compatible!

Named Scopes Are Dead



回答3:

Very cool. I was thinking of doing something like this in Javascript but Javascript behaves rather weird.

The statement:

var x = SomeObject;

does not call SomeObject's toString() function. But the statement:

var x;
x = SomeObject;

correctly calls the toString() function as expected.

This prevents Javascript from doing cool stuff with chaining. =(