On Sep 18, 5:44 am, surge <[EMAIL PROTECTED]> wrote: > Well, I decided to bite the bullet and get closer to the metal by > using :joins and :select. That worked great. Now my query is very > compact -- with only those columns I need in the table and there are > no extra count-related queries. It was a bit of a surprise for me that > when :include was used, :select was ignored, but it does make sense.
Yeah, that's the default behavior of eager-loading; it ignores your :select option. > So when I use :select and :join rails creates attr_readers for each of > the selected columns? For example, I used to have lines like <%= > ticket.priority.name %> in my view. When I changed to using :select, I > changed that line to <%= ticket.priority_name %> because in my :select > I retrieve the priority name directly from the db (by joining the > tickets table with the priorities table). So, I was expecting to see > something like "the ticket model doesn't have a member named > 'priority_name'", but nope, no error occurred. So, my guess is that > rails created an attr_reader for each of the columns mentioned > in :select. Is that approximately what happens? That's right. Rails will create an attr_accessor for each column returned by the SQL, irregardless if it's a real column (either from a table or join) or a computed one. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
