Rails Ruby on Rails → 3.x

Comments and changes to this ticket

• You flagged this item as spam.
  

  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?

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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.

  • preloading_obeys_scope.patch 6.9 KB
• 

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

  • Assigned user set to “Pratik”

• You flagged this item as spam.
  

  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.

  • non_preloading_obeys_scope.patch 3 KB

• You flagged this item as spam.
  

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

• You flagged this item as spam.
  

  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 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 June 18th, 2009 @ 04:05 PM

  • Assigned user cleared.
• 

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

  • Milestone changed from “2.x” to “3.x”

  [bulk edit]

• 

  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 February 2nd, 2011 @ 04:40 PM

  • State changed from “open” to “stale”