This project is archived and is in readonly mode.

#2348 ✓stale
James Le Cuirot

Eager loading does not scope

Reported by James Le Cuirot | March 26th, 2009 @ 02:46 PM | in 3.x

Yet another problem with default_scope, I'm afraid, and quite a serious one. It's being ignored during eager loading.


class Tagging < ActiveRecord::Base
  belongs_to :tag
  default_scope :conditions => { :enabled => true }
end

class Tag < ActiveRecord::Base
  belongs_to :tagging
end

default_scope will work when calling Tag.first.tagging but not Tag.first(:include => :tagging). I'm trying to come up with a patch but I'm struggling. The eager loading stuff is hard to understand.

Comments and changes to this ticket

  • James Le Cuirot

    James Le Cuirot March 26th, 2009 @ 03:18 PM

    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?

  • James Le Cuirot

    James Le Cuirot March 26th, 2009 @ 03:59 PM

    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.

  • Eloy Duran

    Eloy Duran March 26th, 2009 @ 04:06 PM

    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.

  • James Le Cuirot

    James Le Cuirot March 27th, 2009 @ 11:08 AM

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

  • Eloy Duran

    Eloy Duran March 27th, 2009 @ 11:13 AM

    • Assigned user set to “Pratik”
  • James Le Cuirot

    James Le Cuirot March 27th, 2009 @ 03:05 PM

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

  • James Le Cuirot

    James Le Cuirot March 27th, 2009 @ 06:08 PM

    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.

  • Pratik

    Pratik May 18th, 2009 @ 09:26 PM

    • State changed from “new” to “invalid”

    I don't think the associations should be respecting the default scope conditions. This is intended behaviour the way I see it.

  • James Le Cuirot

    James Le Cuirot May 18th, 2009 @ 09:36 PM

    • Title changed from “Eager loading does not respect default_scope” to “Eager loading does not scope”

    Pratik, please read the rest of the ticket. This isn't just about default_scope. The title is actually misleading and I will now change it. Note in particular the change in behaviour between Rails 2.2 and 2.3. I don't use default_scope anymore because I find it works against me most of the time but I still need this fix for scopes in general.

  • Eloy Duran

    Eloy Duran June 18th, 2009 @ 03:51 PM

    • State changed from “invalid” to “open”

    On request of James I re-opened this ticket, as it does no longer concern only the issue as mentioned in the original title.

  • Pratik

    Pratik June 18th, 2009 @ 04:05 PM

    • Assigned user cleared.
  • Jeremy Kemper

    Jeremy Kemper May 4th, 2010 @ 06:48 PM

    • Milestone changed from 2.x to 3.x
  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:40 PM

    • Tag changed from 2.3.2, activerecord, active_record, bug, default_scope, eager, eager_loading, include, loading to 232, activerecord, active_record, bug, default_scope, eager, eager_loading, include, loading
    • Importance changed from “” to “”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:40 PM

    • State changed from “open” to “stale”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Referenced by

Pages