-
-
Save tenderlove/915852 to your computer and use it in GitHub Desktop.
# totally contrived example | |
User.select(Account[:name]).join(:accounts).where(User[:id].in(Group.where(:name => 'foo'))) |
Your example (self-referencing associations) is precisely the reason I need to maintaining the context, and can't stomach the Person[:name] solution. :( We need to "mount" the constraints, for lack of a better term, on the proper table alias. Squeel does that right now via mapping the hash keys (or keypaths in the case of children.children.children) against the corresponding joins in the JoinDependency, then grabbing the JoinAssociation's table. Hope that makes sense.
See my post in the other thread for the pull request for sample queries and actual output.
Also, I think I'm stealing your "putting lipstick on a pig" line for Squeel. It just fits.
lol! Please take it! :-D
@tenderlove: see activerecord-hackery/squeel@f33784217e3bbb030c21
FWIW: evaluate was a typical case of overthinking -- I didn't like stomping on Kernel#eval, even though there's no reason to care in this case. :)
WRT join context, I see your point. But at the same time we can't be sure that the aliases we're picking are correct. For example, selecting from a self join:
Do you select from the original table name, or the aliased table name? Even with context, that case (I think) would be ambiguous. Either we can guess (and possibly go wrong), or give the user exactly what they asked for with no guesses. Of course that means they would have to do extra work in the case of aliases.
WRT lazy evaluation in Squeel: I like it. I think it's good enough to get the job done (though I think you should rename the method to
eval
;-) ).I think I'm more and more convinced of a couple things:
Model[:id]
, they should just use Squeel