Eager loading does not scope

Actually the problem goes deeper. This doesn't work either.

Tagging.send(:with_scope, :find => { :conditions => { :enabled => true } }) do
  Tag.first(:include => :tagging)
end

What is the intended behaviour here?

I've thought about it some more and an easy workaround is to duplicate the default_scope in the association definition like so.

class Tag < ActiveRecord::Base
  belongs_to :tagging, :conditions => { :enabled => true }
end

The only side-effect is that the condition appears twice in the query. I wasn't sure whether applying the default_scope for eager loading was actually a good idea but it is more flexible than the above fix in that the effect can be reversed using with_exclusive_scope. It's also important to have consistent behaviour with manually fetching as associated record.

Could you please try to create a failing test case for Rails, or if easier for some reason only for this fork of Rails: http://github.com/Manfred/rails/...

That fork of Manfred is where some of us are re-thinking how scopes should work. This will take some time though, so I'd advice you to use the workaround for the time being.

Thanks.

This may be even more serious than I thought. I haven't tried it but it appears that my with_scope example above would have worked in Rails 2.2. The change in behaviour was a direct result of ticket #643 named_scope with eager loading affects activerecord objects and this subsequent commit. For some reason, they took the fix one step too far by using an exclusive scope for all associations, not just self-referential ones.

This only concerns the preloading case though. I have yet to fully investigate the non-preloading case. In the meantime, here's a patch with a test that fixes the preloading case.

Here's a patch with a test for the non-preloading case. This one is less pretty because with_scope is awkward to work with. I suppose I could have split it out into a separate method but committing my (very simple) patch in ticket #1331 Allow arbitrary named_scope instances to be merged could also make this nicer.

There is no need to make the klass != self check for self-referential associations in this case because the table is joined on itself using an alias. Unless you specifically reference the aliased table, a scope will only apply to the original table anyway.

It's worth noting that there is also a subtle difference in behaviour between preloading and not preloading here. The scope of the associated model will affect how the parent model records are returned when not preloading, but it won't have the same affect when preloading because this happens in a separate query.

Non-preloading still can't be triggered by the scope. Even if my original example actually said default_scope :conditions => "tagging.enabled = 1" instead, it would still preload and this condition would not affect which Tag records are returned, only which Tagging records are included with the Tag records. I think this makes sense.

I was going to say I forgot to tackle construct_finder_sql_for_association_limiting but it turns out I didn't need to. It already works with the above patch.