[Ruby] Dumb ActiveRecord question

[Alex Vollmer]

This made a major difference in the performance of the app. What was an
85-second query dropped to  milliseconds. The SQL generated by the
associations I had mapped was causing sequential scans across a very large
table. While the solution I came up with works, right now I'm inclined to
think that it's more likely I'm not using ActiveRecord correctly than
ActiveRecord is doing something degenerate. A little quality time with the
docs and a beer may perhaps provide some enlightenment. ;-)

As for testing, the actual caching behavior is stuffed into a mixin module
that has some nice unit-tests around it. The whole thing was test-driven and
working like a charm in unit-test-land. That's the reason I was so flummoxed
by the behavior I was seeing.

Cheers,

Alex V.



On 1/5/07, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>
>
> On Jan 5, 2007, at 2:06 PM, Alex Vollmer wrote:
>
> > Get yer rotten veggies ready for this one...
> >
> > I have a bunch of lookup data in a couple of tables that gets
> > referenced
> > over and over and over. When I include these lookup tables in a
> > has_manyassociation with an
> > :include declaration, ActiveRecord creates some LEFT OUTER JOIN SQL
> > that
> > performs a sequential table scan.
>
> As pointed out, development mode is trashing your class. There are
> ways around that like putting the data outside the class, of course,
> but I'm wondering how much measuring you've actually done before
> caching this info. Premature optimization and all that...
>
> Also, did you write any tests for this caching behavior?
>
> _______________________________________________
> Ruby at zenspider.com - Seattle.rb non-commercial list
> http://www.zenspider.com/seattle.rb
> http://www.zenspider.com/mailman/listinfo/ruby
>



-- 
"I think there are only three things America will be known for 2,000 years
from now when they study this civilization: the Constitution, jazz music,
and baseball."
--Gerald Early