aboutsummaryrefslogtreecommitdiffstats
path: root/tools/console
diff options
context:
space:
mode:
authorSean Griffin <sean@thoughtbot.com>2015-06-30 09:53:56 -0700
committerSean Griffin <sean@thoughtbot.com>2015-06-30 10:00:30 -0700
commitbc6ac8609cf79f28047c0928b9433e00e6ea1f09 (patch)
treec7aba6513e16d0abb3e700ad87ee558929df4945 /tools/console
parentf55c60f5aec67aaa2b1614a59f9a3639f966ea30 (diff)
downloadrails-bc6ac8609cf79f28047c0928b9433e00e6ea1f09.tar.gz
rails-bc6ac8609cf79f28047c0928b9433e00e6ea1f09.tar.bz2
rails-bc6ac8609cf79f28047c0928b9433e00e6ea1f09.zip
Correct through associations using scopes
The changes introduced to through associations in c80487eb were quite interesting. Changing `relation.merge!(scope)` to `relation = relation.merge(scope)` should in theory never cause any changes in behavior. The subtle breakage led to a surprising conclusion. The old code wasn't doing anything! Since `merge!` calls `instance_exec` when given a proc, and most scopes will look something like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing the return value, it's a no-op. However, removing the `merge` causes `unscope` to break. While we're merging in the rest of the chain elsewhere, we were never merging in `unscope` values, causing a breakage on associations where a default scope was being unscoped in an association scope (yuk!). This is subtly related to #20722, since it appears we were previously relying on this mutability. Fixes #20721. Fixes #20727.
Diffstat (limited to 'tools/console')
0 files changed, 0 insertions, 0 deletions