diff options
| author | Sean Griffin <sean@thoughtbot.com> | 2015-06-30 09:53:56 -0700 |
|---|---|---|
| committer | Sean Griffin <sean@thoughtbot.com> | 2015-06-30 10:00:30 -0700 |
| commit | bc6ac8609cf79f28047c0928b9433e00e6ea1f09 (patch) | |
| tree | c7aba6513e16d0abb3e700ad87ee558929df4945 /railties/test | |
| parent | f55c60f5aec67aaa2b1614a59f9a3639f966ea30 (diff) | |
| download | rails-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 'railties/test')
0 files changed, 0 insertions, 0 deletions