> You were partially correct about the relational listing concept. Rails > 2.1's eager loading will use 2 SQL statements when you add > the :include => :issues option: 1 for the tickets table, and 1 for the > issues matching those tickets (in the form of a WHERE IN clause). It's > up to AR to compose those records to AR objects with 1-to-many > associations. > > If you have a :condition which specifies something like > > :condition => "issues.active = 1" > > You get the scenario which you stated: a cartesian product of the > resultset. If you have 100 tickets with 100 issues each, you get > 100x100 = 10,000 records, which AR has to compose into 100 AR objects > with a 1-to-many associations. It doesn't mean that the tickets will > be listed 100 times each, it's just that the resultset will return the > tickets 100 times each. But still, a cartesian product is not a very > good thing from an optimization point of view.
Good points... > :select => "*, COUNT(...) AS issue_count" Aha! Now, that's exactly what I was looking for! I will just need to add a "group by". > Although there's a caveat with the :select approach: AFAIK, MySQL 4.1 > does not support subqueries, 4.1. supports subqueries, but why would I need them in this case? Isn't it just an aggregate function? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
