On 9/14/07, Trevor Squires <[EMAIL PROTECTED]> wrote: I guess the issue I have with your destructive patch is that it hobbles > existing behavior which (for me) returns a predictable dataset. >
Indeed it should be predictable to anyone who has a working knowledge of SQL databases. The reason I don't see it as hobbling is because it seems that the cases where you want that behavior are far outnumbered by the cases where you don't. I've always known that :conditions which relate to :included associations > can cause only part of the association's data to be loaded (I think that's > been referred to as the mephisto bug). When I've used it in the past it's > been because that's exactly what I want. > And if you do understand what's going on, how hard is it to write the JOIN you want explicitly? Setting aside the performance issues (which you address in your > non-destructive patch), the problem as I see it is that there is no way to > tell find() that you want certain conditions applied in the prequery and a > *different* set of conditions applied in the data-loading query (which I'll > call 'realquery' from now on). > > > For the times when I have wanted *all* of the association's data yet > wanted to limit the top-level selection based on association conditions I've > done my own prequery (with a limit) to grab the id values I want to present. > I wrote a plugin that makes these prequeries a little easier to generate - > http://svn.protocool.com/public/plugins/values_of > That's a great idea... I'll probably make use of that plugin myself. > That allows me to have 2 sets of :conditions - one for the prequery and > one for the realquery - and guarantees that my constraints are always true > for my returned data. > > > So... what I'm thinking is this: what about adding a new option to find() > that allows you to specify 'prequery-only' conditions? For example, > something like a :limit_conditions option that utilized your non-destructive > patch? > > > * The :limit_conditions option would only be valid in conjunction with > :limit. > * Both :limit_conditions *and* :conditions options would be applicable to > the prequery. > * Your non-destructive patch would determine the minimum joins required in > the prequery based on :limit_conditions and :conditions > * The :conditions would only be applied to the realquery > I like this idea. Would you be willing to write a patch to do this? If so I'd give it a +1, although my gut instinct is that Koz would -1 since he's expressed reservations about limited eager loading in general. In any case, my agenda right now is to try to push through the first patch. I don't have any need for this specific behavior, though if the first patch doesn't go through, I might find some time down the line to implement something like this. Ultimately I have to admit that when performance is a concern or the > relations are hairy I will probably continue to reach for values_of() and > another (soon to be released) plugin that hydrates associations with > subsequent queries rather than with big-honking-joins. > What is this other plugin? I am mulling over the idea of how to make eager loading more flexible. I have a couple different approaches in mind. One would be to extend :include to somehow indicate how the associations should be split into different queries. The other idea I had is some way of hydrating from more arbitrary queries like explicit :select/:joins or even find_by_sql. Are you working on this? If so I'd be interested in seeing your approach and doing some collaboration... hit me up off-list. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
