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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Chris Hoffman 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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 Francis <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Chris Hoffman 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 > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 2/7/07, Chris Hoffman <bosshoff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.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 Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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. On Feb 7, 9:18 am, "Rick Olson" <technowee...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 2/7/07, Chris Hoffman <bossh...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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. > > 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 Olsonhttp://weblog.techno-weenie.nethttp://mephistoblog.com--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
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 On Feb 7, 9:32 am, Lonnie <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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 > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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? > > -ChrisI 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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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? On Feb 7, 10:47 am, Lonnie <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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 > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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.> > On Feb 7, 10:47 am, Lonnie <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> 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 >> >> -- >> Posted viahttp://www.ruby-forum.com/. > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hello Chris, 2007/2/7, Chris Hoffman <bosshoff@gmail.com>:> 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/ --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---