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
-~----------~----~----~----~------~----~------~--~---

Reply via email to