ActiveRecord: use association's unscope when preloading

[jbourassa]

Preloading an association that is using unscope is dropping the unscope part.

As they say, 10 LoC is worth a thousand words:

class Developer < ActiveRecord::Base
  default_scope -> { where(awesome: true) }
end

class Project < ActiveRecord::Base
  has_and_belongs_to_many :developers, -> { unscope(where: :awesome) },
end

mediocre_dev = Developer.create(awesome: false)
project = Project.create
project.developers << mediocre_dev

project.developers.reload.size
# => 1
Project.where(id: project.id).includes(:developers).first.developers.size
# => 0 — but should be 1

This PR fixes that behaviour. This is my first PR on AR (:tada:) so I'm not all that familiar with the internals, let me know if anything seems wrong.

[markets]

Hi @jbourassa, I think this topic is also addressed here: #11036, #11082, #16531, #18983.

Seems like statements with unscoped (or unscope) + preloading are broken in AR4+.

[jbourassa]

@markets Thanks for the heads up. I think they're all still valid issues albeit somewhat outdated. Part of #16531 (this) has already been implemented, and this PR builds on top of that change.

[eileencodes]

Thanks for the PR! 😄 New code added to Rails should use the new hash syntax. foreign_key: "project_id"

[jbourassa]

Thank you. I updated the PR accordingly.

[markets]

Yes, they are still valid in latest 4.2-stable (not tried in master). I, particularly, want to fetch objects via associations like this:

has_manny :comments, -> { unscoped } # fetch comments by-passing the default_scope

But I didn't found a way to achieve that. So, finally I wrote a gem unscoped_associations, it works for has_many, has_one, belongs_to; but it causes some issues (N+1) on preloading an unscoped association. I also see similar issues in other gems extending/patching AR (zendesk/predictive_load#6, salsify/goldiloader#13), so would be really nice to have this merged it in 👍 and have a clear way to fetch objects via associations by-passing the default_scope.

[jbourassa]

@eileencodes Sorry to ping you but I was expecting to hear from @rails-bot, but it's not happening. Any idea what needs to be done to get this in? Thanks!

[sgrif]

Thanks. I added a changelog entry for you as part of the merge commit, please make sure to add one when fixing bugs in the future.

[sgrif]

Also if you notice that after you update a PR that Travis hasn't picked it up, you can help us out by clicking close and re-open which should force it.

[sgrif]

Backported to 4.2 in 338894c

[jbourassa]

🎉 awesome, thank you very much @sgrif.

I'll make sure to edit the changelog next time.

[sgrif]

Thanks for the great patch!

[GuyPaddock]

I'm using this patch but this still doesn't work:

belongs_to :membership, -> { unscoped }

We have a soft-deleted loyalty membership that is normally hidden by the default scope (deleted_at has to be nil). The only workaround at the moment is for us to explicitly specify:

belongs_to :membership, -> { unscope(where: :deleted_at) }

But this couples the referencing object to the column in the membership model, when we would prefer to do:

belongs_to :membership, -> { with_deleted }

[sgrif]

@GuyPaddock Please create a script we can use to reproduce the issue using this template, and open a new issue.

[philipgiuliani]

@GuyPaddock have you found a workaround for unscoping the asosciation? I updated to rails 4.2.5.rc1 but i still wasn't able to do this.

[kashifnaseer]

its still an issue in Rails 4.2.4. Any suggestion, how i can get this working in Rails 4.2.4 ?
As it is mentioned above that it has been backported to 4.2, should it not work with 4.2.4 ?

[jbourassa]

@kashifnaseer this has been released in 4.2.5, so it will not work in 4.2.4.

This may not work with belongs_to associations, as reported by @GuyPaddock — I'm not sure which code path is being used for belongs_tos.

[nosleinfull]

Still does not working for this case :(

class Developer < ActiveRecord::Base
  default_scope -> { where(awesome: [1,2,3]) }
end


class Project < ActiveRecord::Base
  has_and_belongs_to_many :developers, -> { unscope(where: :awesome) },
end

mediocre_dev = Developer.create(awesome: 0)
project = Project.create
project.developers << mediocre_dev

project.developers.reload.size
# => 0 — but should be 1
Project.where(id: project.id).includes(:developers).first.developers.size
# => 0 — but should be 1

[jbourassa]

@nosleinfull 🤔 looks like the behaviour you're reporting is triggered regardless of preloading, eg there's no preloading in this piece of code:

project.developers.reload.size
# => 0 — but should be 1

right?

I tried reproducing in a test on master using very similar setup (default scope with a lamda and IN filtering), but couldn't. Can you come up with a failing test?