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