On 14 Jan 2008, at 14:41, Phlip wrote:
>
> To ensure your test cases call efficient MySQL...
>
> def test_my_case
> assert_efficient_sql do
> # just wrap them in this block!
> end
> end
>
This looks very interesting! I do have one reservation, which
basically boils down to ''the test database is very small''.
For example my customer fixtures define a dozen or so customers
whereas obviously the production version contains a hell of a lot
more. So no matter what I do in my code, I''m unlikely to hit
the :throttle limit. Is it not also the case that mysql might choose a
different query plan depending on index statistics etc... which are
likely to be profoundly different in the production (or even
development) databases ?
I imagine one could lean on this to produce some sort of continuous
integration system which would test core ''routes'' through the
system
for regressions in this area
Fred
> The assertion intercepts and copies out your MySQL SELECT
> statements, then
> calls EXPLAIN on each one, and inspects the results for common
> problems.
>
> The goal is test cases that resist database pessimization, even as
> you change
> your data relations, to add new features. If you run your tests after
> every few changes, you can easily detect which change broke your
> database''s
> indices and relations.
>
> Blog:
>
> http://www.oreillynet.com/ruby/blog/2008/01/
> assert_efficient_sql.html
>
> RDocs:
>
> http://efficient-sql.rubyforge.org/
>
> --
> Phlip
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---