>> performance characteristics. Removing the limit will make the
>> database examine multiple rows, lots of them in your case, which won't
>> be ideal.
>
> You are right - but this would only happen once, because we'd then get an
> exception and fix the bug. Otherwise the bug might never be noticed.
>
> Adding a limit 1 clause does not guarantee good performance. Just take a
> "select * from users order by random() limit 1". This can be *very slow* if
> users has many rows because the whole set gets ordered before only a single
> result is returned.
> If you are really concerned about performance (it should never be a problem
> once there are no bugs/ bad designs left), just replace the LIMIT 1 with a
> LIMIT 2. As soon as we get > 1 rows we can still raise.
You seem to misunderstand my objection. Running the query as you
suggest is definitely what your application should do, and anyone
else's application which cares about which particular matching value
they get back. However to change *already running* applications to
suddenly issue a pretty drastically different query isn't backwards
compatible by any reasonable definition.
>> The dynamic finders are currently a small piece of syntactic sugar for
>> 'where x = ? limit 1', I'm not sure that changing them to do something
>> more complete really gains us much.
>
> As explained in my first post I think there are huge gains in terms making
> users aware of design flaws in their code and so preventing them from
> potential security issues in their apps.
You're projecting your own use case onto all users of all dynamic finders.
@blog.posts.random.find_by_category("cool") # where random is
order('rand()') or similar
That's a perfectly valid use and would no longer be supported by what
you're proposing.
--
Cheers
Koz
--
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.