Why the preference for find(:all)?

rubyonrails-talk
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

3

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.

4

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.

5

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

6

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?

7

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.

8

Hello Chris,