When I've been teaching Rails I've often found that people expect find(:first) to return the record with the lowest id number, which is often not the case. find(:one) would probably remove that bit of confusion.
But I agreee that once you add an :order clause, find(:first, :order => ... ) makes more sense :).
-Jonathan.
On 8/31/06, Damian Janowski
<[EMAIL PROTECTED]> wrote:
Because find(:first) will actually bring you the first record of the result set. If you include :conditions and :order, then you have a restricted set with a specific order. Then :first makes sense.Although find(:one) would be awesome for doing a random -- "bring me a random record from this result set" :)
From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Viney
Sent: Wednesday, August 30, 2006 8:48 PMSubject: [Rails-core] Re: :throw option for AR finders that don't throw RecordNotFound exceptionsAnother thought .... how about replacing find(:first) with find(:one). :first implies some sort of order where none actually exists.
-Jonathan.
On 8/31/06, Damian Janowski <[EMAIL PROTECTED]> wrote:
IMHO bang wouldn't follow Ruby's convention (ie that "!" makes something
destructive to the object).
Something along "find_or_raise" would follow Rails' "find_or_create"
convention.
But +1 to load vs find. Sounds cool.
-----Original Message-----
From: [email protected]
[mailto: [email protected]] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, August 30, 2006 5:33 PM
To: [email protected]
Cc: [email protected]
Subject: [Rails-core] Re: :throw option for AR finders that don't throw
RecordNotFound exceptions
Chris Wanstrath wrote:
> I agree with you guys, all I'm saying is that if we go ahead with
> find! we will have a `find' which does about a million different
> things. It sometimes raises exceptions if there's a bang and
> sometimes raises exceptions if there's not a bang. Complexity?
>
> I like what Jeremy is saying about load vs find. I think that's what
> I'm reaching for. When you find(13) you're asking Rails to load a
> specific record. When you find_by_id(13) you're like "hey give me
> this if you can, if not that's cool too." Maybe that is a route to
> discuss.
Yep. I brought up the point of find() being way overloaded back in Feb, and
got no traction. The current find() API is about 3 different APIs rolled
into one method. When not finding a record, find will either throw an
exception, return nil, or return an empty array, depending on if it was
called by id, :first, or :all. Having the method parse its params to
determine how to handle things is ugly. Yes, it's the same as
render(:whatever), but it's still ugly, moreso since the id case can accept
several kinds of values (int, list, array). Adding a find! and
find_by_whatever! and find_or_create_by_whatever! might have advantages in
places, but if we're really going there, can we maybe come up with a big
picture of where we want to be long-term and then figure out how to get
there in a way that's not too painful?
load() vs find() could be a good start, but it's obviously a 2.0 kind of
change since it is not backward compatible. My vote would include separating
the find(id), find(:first) and find(:all) cases into separate methods. I
know find_first and find_all are deprecated (for good reason - the
positional parameter API sucked), but perhaps something like find_one and
find_many would work.
--
Josh Susser
http://blog.hasmanythrough.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---
