diff options
author | Ryuta Kamizono <kamipo@gmail.com> | 2019-03-29 18:21:56 +0900 |
---|---|---|
committer | Ryuta Kamizono <kamipo@gmail.com> | 2019-03-30 04:18:25 +0900 |
commit | 2d12f800f1c6b0a2018346e0139301070273e46f (patch) | |
tree | 14e8071407f733ef9acef4cb67b1494b45d05fb0 /railties/lib/minitest | |
parent | da2c92377c7f36469e56dc25a4ac0604157ac778 (diff) | |
download | rails-2d12f800f1c6b0a2018346e0139301070273e46f.tar.gz rails-2d12f800f1c6b0a2018346e0139301070273e46f.tar.bz2 rails-2d12f800f1c6b0a2018346e0139301070273e46f.zip |
Type cast falsy boolean symbols on boolean attribute as false
Before 34cc301, type casting by boolean attribute when querying is a
no-op, so finding by truthy boolean string (i.e.
`where(value: "true") # => value = 'true'`) didn't work as expected
(matches it to FALSE in MySQL #32624). By type casting is ensured, a
value on boolean attribute is always serialized to TRUE or FALSE.
In PostgreSQL, `where(value: :false) # => value = 'false'` was a valid
SQL, so 34cc301 is a regresson for PostgreSQL since all symbol values
are serialized as TRUE.
I'd say using `:false` is mostly a developer's mistake (user's input
basically comes as a string), but `:false` on boolean attribute is
serialized as TRUE is not a desirable behavior for anybody.
This allows falsy boolean symbols as false, i.e.
`klass.create(value: :false).value? # => false` and
`where(value: :false) # => value = FALSE`.
Fixes #35676.
Diffstat (limited to 'railties/lib/minitest')
0 files changed, 0 insertions, 0 deletions