Well just to be clear, I'm not talking about an ad-hoc patch here. I'm presenting a specific scenario as an example, but it touches on a whole class of issues with field and table name collisions, and the inclusion and exclusion of various clauses. I expect there's a lot of collective wisdom here about various edge cases which is what I'm hoping to tap into.
I'm doing some pretty heavy advanced search form stuff with ActiveRecord; really pushing the envelope with limited eager loading, and I gotta say it's held up fairly well (it's better now than with Rails 1.2.3). My impressions are that: * The SQL error usually is just as informative as whatever AR might easily be made to spit out. * Determining the error condition would require just as much work as actually fixing it in a lot of cases. * I'd rather see documentation of the incompatible options, as by the time I hit the error, it's usually not hard to figure out what's going on. Documentation would alert more people to the limitations before they actually run into them. I think looking at other ORMs for ideas would be great, however I'm a little concerned that a truly robust solution starts to approach the complexity of a full SQL parser. I don't want people to be discouraged by the complexity and conclude that ActiveRecord shouldn't support that on grounds of complexity alone. I like the fact that ActiveRecord doesn't try to do everything, but I feel pretty strongly that we need more robust eager loading because it's such an essential feature. Often times it's a performance necessity, and it's one area where falling back to find_by_sql just doesn't work because you can't easily construct the association targets from a raw sql query. On 6/29/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > > As it turns out, extending the order clause doesn't even work for > > eager loading with a limit clause since the initial query to find the > > IDs doesn't include the joined table, and therefore the clause blows > > up. ActiveRecord will need to parse the order string to prevent this > > condition... As it is, I'll have to either not eager load the > > association (n+1 ugh), or else sort the association after it is loaded > > (not bad for small associations, but not very DRY). > > > > Does AR do any analysis of ORDER clauses currently? > > Limits, orders etc with Eager includes are bit of a nonsense feature > as is, and the limitations of their implementation highlights that. > Rather than take some ad-hoc patches to fix a few specific broken > cases, I think the best bet is to either: > > * Rethink how they can / should work to get something a little more robust; or > * Figure out what situations won't work correctly with our current > implementation and raise useful errors instead of 'kinda working'. > > Does anyone have any strong feelings on the matter? I'm sure some of > the other ORMs like hibernate and toplink have an implementation that > could provide clues to a sane approach? > > -- > Cheers > > Koz > > > > -- Gabe da Silveira http://darwinweb.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
