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.
I concede it would be useful to have a more-flexible form of ActiveRecord#exists? so I could check whether too-many results would be returned by a set of conditions, but without having to invoke a large COUNT. Perhaps something like ActiveRecord#exists_more_than_n_records?(n) This way I could ask ((find :all, :limit => n+1).size > n) On Thu, Jul 30, 2009 at 10:22 AM, Joris <jbversch...@gmail.com> wrote: > > Hi guys, > > Pratik pointed me here. I have submitted feature request #2974. > > It's basically a new finder: unique. To be used at times where people > use :first. > Often, you query for something, and expect only a single record. > > To do this, people use :first. However, :first does not check for any > following entities. This means that if the developer expects 1 > records, and gets more than 1 the application will 'just work'. > > I don't think this is correct behaviour. Also, :first and :last mean: > first / last of the list. If you're looking for a single row, unique > makes more sense > > > > --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
