On 7/1/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > 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?
You are more familiar with the code than me, so I could be overlooking something here. However if you append association :order to the end of the ORDER clause, it shouldn't affect the main :order specified in the base query. Likewise, leaving the assocation :order it out of the ID-fetching query ensures we get the right number of, and correct base objects. If I'm totally missing your point please explain. > > 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? Well I certainly want to contribute something useful and robust back to ActiveRecord. At this point I'm just brainstorming attack vectors to the problem though. I'm looking for any specific warnings, pitfalls, or edge cases that I should be thinking about. I'm not sure what you mean by inconsistent behaviour, but my only goal here is making things work that seem like they should work. The expected behaviour should be obvious, so I guess I'm not seeing where the inconsistency would arise (unless I screwed something up). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
