2009/8/31 Tony <tony.cassan...@gmail.com>: > > On Aug 31, 12:39 am, Colin Law <clan...@googlemail.com> wrote: >> 2009/8/31 Tony <tony.cassan...@gmail.com>: >> >> >> >> > Maybe I'm missing something but I don't see any way to get eager >> > loading with the named scopes. I have many Event models each with >> > many Stat models. If I have to query each event to get the summary, I >> > still have the n+1 query problem. >> >> Don't follow you here, it should be just one query for each event to >> get the stat summary for that event. >> >> Colin >> > > Ooops, sorry about that. So it is indeed one query per event, > however, I need a list of N events all at the same time. I didn't > mean to imply that it is N queries per event, rather that it is N > queries per page load. The page is loading N events and their > summaries (kinda like a dashboard...). This means that I'd need a > query for every Event to fetch the summary, thus the N queries, + 1 > for the initial fetching of the events. If I were to stuff this in an > association I'd have 2 queries only (one for the events and one for > all of the summaries). If I were only displaying a few Events per > page I wouldn't be concerned, however, 10, 20, 30+ queries for a > single page would begin to impact performance, I imagine. I'd really > like to replicate the performance of a find using :include. > > If the only way to get that performance is to use a separate model > (SummaryStat) and mark it as readonly, I'm happy to do it. I was > simply hoping for a more concise and readable way of doing this. I > got very close to being able to do it in a concise way using the > normal has_* relationships, however, has_one doesn't support grouping > which I needed for this particular query.
I think you are worrying too much about performance at this stage. Do it whichever way seems most natural to you initially and worry about performance later. My experience is that when performance problems arise it is almost never the area that I expected to be the bottleneck that is causing the problem and so to spend time worrying about it too much at the start is a waste of time. In fact the approach I suggest does not preclude using a single query to get all the summaries for a set of events. Just make the class method of Stat that I am suggesting takes a single event take an array of or events instead, run the single query, and return an array of stats. As I said though I would suggest doing it the easy way first and worry about additional complications if performance becomes an issue. So I would still suggest A class method of Stat, get_summary_for_event( event ) that runs the summing query and returns the summary An instance method of Event, summary that calls Stat.get_summary_for_event( self ) and returns it. It seems difficult to get a more concise and readable way of doing it than that. However, as I said, I would suggest doing it whichever way seems most natural to you, which is the 'best' way of doing things is often more about how ones brain sees the problem than about some supposedly ideal solution. Colin --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
