Fix bug with symbolized keys in .where with nested join (alternative to #27598) #27599
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In #25146, code was added to fix making where clauses against tables with an
enum
column with ajoin
present as part of the query. As part of this fix, it calledsingularize
on thetable_name
variable that was passed into theassociated_table
method.table_name
, in some circumstances, can also be a symbol if more than one level of joins exists in the Relation (i.ejoins(:book => :subscription)
). This fixes that by adding chaning the.stringify_keys!
(found inActiveRecord::Relation::WhereClauseFactory
) to be a.deep_stringify_keys!
to stringfy keys at all levels.Other Information
This bug only surfaces when a join is made more than 1 level deep since the
where_clause_builder
callsstringify_keys!
on the top level of the.where
hash:https://github.com/rails/rails/blob/21e5fd4/activerecord/lib/active_record/relation/where_clause_factory.rb#L16
So this hides this edge case from showing up in the test suite with the current coverage and the test that was in PR #25146.
This is the alternative to #27598 in which the change from PR #25146 was fixed in isolation. Instead, here we fix the false assumption that all
table_name
values being passed into.associated_table
are a string. This might have wider effects because of that, so that should be considered when reviewing.