missing interpolate_sql in JoinAssociation

Hi List,

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.

Cheers, Ian White

Hi List,

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.

-Jonathan.

Hi Rick,

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).

Cheers, Ian

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

... let me know if this works out.

Sure does, thanks!