diff options
author | Sean Griffin <sean@thoughtbot.com> | 2015-01-24 19:51:26 -0700 |
---|---|---|
committer | Sean Griffin <sean@thoughtbot.com> | 2015-01-24 19:51:26 -0700 |
commit | c80487eb1ae7f35cc780745b4f951a79e1a3482b (patch) | |
tree | 17be8fca763795483be08cb2aa15344859462838 /guides | |
parent | 4c0a9922d6bc608e330740b4384c418fe69fc587 (diff) | |
download | rails-c80487eb1ae7f35cc780745b4f951a79e1a3482b.tar.gz rails-c80487eb1ae7f35cc780745b4f951a79e1a3482b.tar.bz2 rails-c80487eb1ae7f35cc780745b4f951a79e1a3482b.zip |
Don't rely on relation mutability when building through associations
Specifically, the issue is relying on `where_unscoping` mutating the
where values. It does not, however, mutate the bind values, which could
cause an error under certain circumstances. This was not exposed by the
tests, since the only place which would have been affected is unscoping
a boolean, which doesn't go through prepared statements. I had a hard
time getting better test coverage to demonstrate the issue.
This in turn, caused `merge` to go through proper logic, and try to
clear out the binds associated with the unscoped relation, which then
exposed a source of `nil` for the columns, as binds weren't expanding
`{ "posts.id" => 1 }` to `{ "posts" => { "id" => 1 } }`. This has been
fixed.
The bulk of `create_binds` needed to be moved to a separate method,
since the dot notation should not be expanded recursively.
I'm pretty sure this removes a subtle quirk that a ton of code in
`Relation::Merger` is working around, and I suspect that code can be
greatly simplified. However, unraveling that rats nest is no small task.
Diffstat (limited to 'guides')
0 files changed, 0 insertions, 0 deletions