2009/7/31 Joris Verschoor <[email protected]> > > If you know something should return a single row, then you might as > well check check if it's really the case. > > Also, first has a different meaning than one/unique. > If I say that I want the first of a query, there could be more results > in the resultset. > > The 'first user' example is a good example of a case where you'd want > to use first. You could also use last. > But the second query, if username should be unique, User.one or > User.unique better states what you're trying to do. You could also > write User.last(.....), but that would look awkward. > > If I would mistakenly write the query this way: > User.first(:conditions => :firstname => 'mislav'), I wouldn't be > notified if the query returned 3 mislav users. >
I have to agree with Mislav and Duncan here, if firstname should be unique, a finder is not the place to enforce that. Those 2 other "mislav" users should not be in the database in the first place! There may be a compelling use-case for a find(:only/unique/make_sure_there_is_only_one_result), but late detection of invalid data isn't it. > On Fri, Jul 31, 2009 at 10:34, Mislav Marohnić<[email protected]> > wrote: > > I'm still not sure what are we tring to solve here. Here's what we have > now: > > User.first(:order => 'id') #=> gets me the first user > > User.first(:conditions => { :username => 'mislav' }) #=> gets me a > > specific user > > I designed the domain model, so I know that "username" is a unique key in > > the database. If I was querying against a column that's non-unique, I > would > > have used User.all(...) and then do some inspecting of the resultset and > > apply some business logic to it. > > How does that "feel" wrong? If an implicit guard like Will Bryant's code > > makes you feel safer, there's nothing preventing you adding it. But I > think > > core material should be something that everybody is encouraged to use—for > a > > solid reason. > > > > On Thu, Jul 30, 2009 at 23:58, Duncan Beevers <[email protected]> > > wrote: > >> > >> This just feels a little backwards. Enforcement of how many records are > >> in the db is not the responsibility of the finder. Uniqueness should be > >> enforced in the database and in the parts of the application that insert > and > >> update data. > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
