Why the preference for find(:all)?

Rails
1

Hello,
I am just wondering if someone could offer an explanation as to why
the preferred way to find records is to use find(:all), and why
find_all is going the way of the dinosaur? I have been implementing
BDD in my code (via rSpec), and the find_all call is far easier to use
in stubbing/mocking (no need to investigate parameters).
What advantages does the find(:all) method offer that I have not yet
seen? Consistency can’t be the answer, as all of the dynamic finders
use this same syntax. Please help me understand this decision.
Thanks.

2

Isn’t there a find_first counterpart as well? It seems as though they
were consistent before, and changing to this parameterized syntax has
gained us nothing.

-Chris

On Feb 7, 9:13 am, Alan F. [email protected]

3

Chris H. wrote:

Hello,
I am just wondering if someone could offer an explanation as to why
the preferred way to find records is to use find(:all), and why
find_all is going the way of the dinosaur? I have been implementing
BDD in my code (via rSpec), and the find_all call is far easier to use
in stubbing/mocking (no need to investigate parameters).
What advantages does the find(:all) method offer that I have not yet
seen? Consistency can’t be the answer, as all of the dynamic finders
use this same syntax. Please help me understand this decision.
Thanks.

I suspect consistency is the answer. find(:all) and find(:first) are
the two alternatives.

Alan

4

On 2/7/07, Chris H. [email protected] wrote:

Thanks.
Flexibility. The old find_first/find_all methods used positional
arguments. At the time, they only supported conditions, joins, and
order, but #find now supports :include, :select, etc.

–
Rick O.
http://weblog.techno-weenie.net
http://mephistoblog.com

5

So changing to symbolized parameters was found to be easiest to do if
the entire method was changed? I admit I haven’t had much experience
with gently deprecating functionality, but I would think it just as
easy to allow two different types of parameter lists. Anyway, at
least I have my answer. Thanks for the fast responses.

6

I’m not sure if it is THE reason, but I rationalized it as a need to
separate the ActiveRecord find_all method from the Enumerable find_all
method. Take for instance the following setup:

class Employer < ActiveRecord::Base
has_many :employees
end

class Employee < ActiveRecord::Base
belongs_to :employer
end

Employer.find(:first).employees.find_all(…)

employees is an ActiveRecord collection, which is an Enumerable. I can
see times were times I want the employees.find_all to be the
Enumerable.find_all instead of the ActiveRecord find_all, and the other
way around as well.

-Lonnie

7

My collegue has a point to add to Lonnie’s remarks: isn’t there also
an Enumerable.find ? How is a potential confound avoided for this
method?

-Chris

8

Chris wrote:

My collegue has a point to add to Lonnie’s remarks: isn’t there also
an Enumerable.find ? How is a potential confound avoided for this
method?

-Chris

I stand corrected and completely agree. You’d think after I took the
time to type out that response that I would have seen the
Enumerable.find method right next to the find_all method. As I look
back into some of my code, I see that I used the Enumerable.detect
method (of which Enumerable.find is a synonym for) to avoid the
confusion I was having.

-Lonnie

9

Chris wrote:

So, I am still left wondering: why was find made not only to support
different kinds of parameters, but also modify its behavior depending
on these parameters, instead of simply supporting different kinds of
parameters under the existing find_all? Wouldn’t the latter scenario
make more sense, and be just as flexible?

I agree that this is a rather baffling aspect of Rails’ design. I don’t
like having to look at the parameters to determine whether a single item
or a collection will be returned.

10

So, I am still left wondering: why was find made not only to support
different kinds of parameters, but also modify its behavior depending
on these parameters, instead of simply supporting different kinds of
parameters under the existing find_all? Wouldn’t the latter scenario
make more sense, and be just as flexible?

11

Hello Chris,

2007/2/7, Chris H. [email protected]:

I am just wondering if someone could offer an explanation as to why
the preferred way to find records is to use find(:all), and why
find_all is going the way of the dinosaur? I have been implementing
BDD in my code (via rSpec), and the find_all call is far easier to use
in stubbing/mocking (no need to investigate parameters).
What advantages does the find(:all) method offer that I have not yet
seen? Consistency can’t be the answer, as all of the dynamic finders
use this same syntax. Please help me understand this decision.

I don’t know the exact answer, but for mocking/stubbing, I don’t
necessarily stub/mock find itself. Instead, I mock #find_all_by_title
instead.

Hope that helps !

François Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/