Recently interpolate_sql has dissapeared from edge in JoinAssociation
(associations.rb)
However there are some lines of code in associations.rb that call this
method, and I'm now getting test failures in my own projects:
NoMethodError: undefined method `interpolate_sql' for
#<ActiveRecord::Associations::ClassMethods::JoinDependency::JoinAssociation:0x398d818>
What's going on? Presumably, at least those method calls shouldn't be
there.
Recently interpolate_sql has dissapeared from edge in JoinAssociation
(associations.rb)
However there are some lines of code in associations.rb that call this
method, and I'm now getting test failures in my own projects:
NoMethodError: undefined method `interpolate_sql' for
#<ActiveRecord::Associations::ClassMethods::JoinDependency::JoinAssociation:0x398d818>
What's going on? Presumably, at least those method calls shouldn't be
there.
Ah, I think I left that out on accident on one of my recent commits.
I'll check it out. What tests are failing? The AR test suite was all
passing when I committed.
This change broke a couple of my tests. I was eager loading association with conditions that contained #{aliased_table_name}. Even though the interpolation can’t include model attributes, it is still useful to be able to substitute the table name in.
To get around the issue, I simply looked at the generated sql and put the aliased table names straight into the conditions, but that is a bit error prone.
Ah, I think I left that out on accident on one of my recent commits.
I'll check it out. What tests are failing? The AR test suite was all
passing when I committed.
The problem occurs when you have a has_many :through a has_many which
has conditions.
Luckily, the AR fixtures have an instance of this type of relationship,
so I wrote a small test (Parked at Loopia) that fails in
the current revision, but passes in r5263 (which I believe is the rev
before the change).
I rolled back the changeset and documented the quirky behavior.
Basically, conditions are usually interpolated in the context of the
actual record. But since the record hasn't been loaded yet with eager
loading, it's interpolated in the context of the class. This gives
you access to the aliased_table_name method which probably comes in
handy for those crazy eager include queries.
Thanks for bringing this up, and let me know if this works out.
I rolled back the changeset and documented the quirky behavior.
Basically, conditions are usually interpolated in the context of the
actual record. But since the record hasn't been loaded yet with eager
loading, it's interpolated in the context of the class. This gives
you access to the aliased_table_name method which probably comes in
handy for those crazy eager include queries.
Makes sense. Also good to have documented exactly why {:conditions =>
"foo = #{foo}"} won't work in this situation but {:conditions => ["foo
= ?", true]} will