This project is archived and is in readonly mode.
Choosing join operator for hash joins
Hash join parameters are great for named_scopes. In particular, if those are about to be chained. The developer can easily add additional joins even if joins in earlier named_scopes are unknown at coding time. A good example would be an authorization plugin, limiting the scope of queries according to authorization rules that are unknown beforehand (we are doing just that in declarative_authorization).
Only being able to use INNER JOINs cripples hash joins, though. OR'ed authorization rules (to stay with the example) won't work if associations are involved as INNER JOIN forces every joined table to have at least one match.
The supplied (very simple) patch adds a :join_operator parameter to find, letting the caller choose if the joins should use :inner_join or :left_join and defaulting to :inner_join, of course.
-
add_join_operator_option.diff
4.64 KB
-
Michael Koziarski- State changed from new to wontfix
I don't really like the API for this as it still suffers from the restriction that all joins have to have the same operator. If we were going to make this more flexible, we should make it so that the operators can be specified on a per join basis.
-
Steffen BartschI understand this objection. The syntax for per-join selection of join operators would be quite ugly, though. But it is really not helpful to resort to :include for LEFT JOINs, so what about this:
Project.find(:all, :joins => { :third_parties => {:branches => :employees}}, :project_managers } :joins => { [:left_join, :third_parties] => { :branches => :employees}}, [:left_join, :project_managers] } -
Michael Koziarski
Yeah, that's quite ugly as you mentioned. Can we hold off making a call till after 2.3? I agree that this is something we have to look at, just don't think we should block a release on it.
-
Steffen Bartsch
Yes, this needs some more discussion. Wasn't meant to block 2.3.