On 7/1/07, Gabe da Silveira <[EMAIL PROTECTED]> wrote: > > I've thought about that in the abstract and it makes a lot of sense. > Another way to add power and flexibility would be public hooks to the > eager loaded table name aliases (maybe this can be done already, it's > just not documented). > > However I think the base case that I'm talking about should definitely > be fixed. It's not some crazy edge case. It's just maintaining the > order of the association. The solution is quite simple: DON'T include > the order clause on the ID-fetching query for limited eager loading, > but DO include it (by appending) on the actual query.
Won't that mean your 'limit / offset' queries aren't guaranteed to page through the system in a consistent and meaningful way? > My entire app is built around search, and I'm leveraging pretty much > all the features of ActiveRecord, so using find_by_sql just isn't > practical. If I were to do so, I would have to write code duplicating > 75% of ActiveRecord functionality just to build my queries. Kind of > like writing an SQL parser is a bad thing for ActiveRecord to do, > writing a query generator that can process :include, :conditions, > :limit, :offset, etc would be a bad thing for my app to do. Sure, but if you wrote one and contributed it back, we'd all be better off :). Either way, yeah, you're definitely right that if we can fix the strangely undefined behaviour, we should. But I don't think that what you're proposing will lead to consistent behaviour? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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-core?hl=en -~----------~----~----~----~------~----~------~--~---
