diff options
author | Sean Griffin <sean@thoughtbot.com> | 2015-01-26 14:44:05 -0700 |
---|---|---|
committer | Sean Griffin <sean@thoughtbot.com> | 2015-01-26 14:44:05 -0700 |
commit | 39f2c3b3ea6fac371e79c284494e3d4cfdc1e929 (patch) | |
tree | 391581e98f3acf78ea1fe47ab737af81470d6e7c /railties | |
parent | 1152219fa2d7968f864b3a5ebb78d2f95ca4fb5c (diff) | |
download | rails-39f2c3b3ea6fac371e79c284494e3d4cfdc1e929.tar.gz rails-39f2c3b3ea6fac371e79c284494e3d4cfdc1e929.tar.bz2 rails-39f2c3b3ea6fac371e79c284494e3d4cfdc1e929.zip |
Change `having_values` to use the `WhereClause` class
This fixed an issue where `having` can only be called after the last
call to `where`, because it messes with the same `bind_values` array.
With this change, the two can be called as many times as needed, in any
order, and the final query will be correct. However, once something
assigns `bind_values`, that stops. This is because we have to move all
of the bind values from the having clause over to the where clause since
we can't differentiate the two, and assignment was likely in the form
of:
`relation.bind_values += other.bind_values`
This will go away once we remove all places that are assigning
`bind_values`, which is next on the list.
While this fixes a bug that was present in at least 4.2 (more likely
present going back as far as 3.0, becoming more likely in 4.1 and later
as we switched to prepared statements in more cases), I don't think this
can be easily backported. The internal changes to `Relation` are
non-trivial, anything that involves modifying the `bind_values` array
would need to change, and I'm not confident that we have sufficient test
coverage of all of those locations (when `having` was called with a hash
that could generate bind values).
[Sean Griffin & anthonynavarre]
Diffstat (limited to 'railties')
0 files changed, 0 insertions, 0 deletions