On Aug 31, 1:31 am, Colin Law <[email protected]> wrote: > 2009/8/31 Tony <[email protected]>: > > > > > > > > > On Aug 31, 12:39 am, Colin Law <[email protected]> wrote: > >> 2009/8/31 Tony <[email protected]>: > > >> > 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
Colin, Thanks again for sticking with me on this. I actually already have this working and am currently cleaning up the code. Your point still stands however, and I probably shouldn't worry about performance too much. I just didn't want to degrade the performance at all from where it stands currently. I'll play with your suggestion. Thanks for the help! As a sidenote: I think the ideal solution would be the ability to specify scope (named or default) with eager loading. There's an open ticket currently regarding this: https://rails.lighthouseapp.com/projects/8994/tickets/2348-eager-loading-does-not-respect-default_scope. Thanks again. tony --~--~---------~--~----~------------~-------~--~----~ 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 [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-talk?hl=en -~----------~----~----~----~------~----~------~--~---
