Repository navigation
Weird params behavior #1828
Description
I was trying to modify the params I was receiving and I was struggling to convert the keys to symbols. I eventually had to settle on params.to_h.transform_keys(&:to_sym) to get it to work. Now, I could've sworn I've never had to do this in the past, so potentially I screwed something up, I just have no idea what. If it isn't an error on my end though, here's some of my output:
#567354) params.is_a? Hash
true
(ruby@puma: cluster worker 1: 567080 [backend]#567354) params.transform_keys(&:to_sym)
{"name"=>"Device 1",
"device_id"=>"D1234",
"scheduled_at"=>"2022-10-19 18:30:08 +0000",
"location"=>"office1",
"first_name"=>"dsf",
"last_name"=>"zdsfgdf",
"password"=>"dsgdf",
"email"=>"dsfgsd@sdfs.com"}
(ruby@puma: cluster worker 1: 567080 [backend]#567354) params.transform_keys!(&:to_sym)
{"name"=>"Device 1",
"device_id"=>"D1234",
"scheduled_at"=>"2022-10-19 18:30:08 +0000",
"location"=>"office1",
"first_name"=>"dsf",
"last_name"=>"zdsfgdf",
"email"=>"dsfgsd@sdfs.com"}
(ruby@puma: cluster worker 1: 567080 [backend]#567354) params.symbolize_keys(&:to_sym)
{"name"=>"Device 1",
"device_id"=>"D1234",
"scheduled_at"=>"2022-10-19 18:30:08 +0000",
"first_name"=>"dsf",
"last_name"=>"zdsfgdf",
"password"=>"dsgdf",
"email"=>"dsfgsd@sdfs.com"}
(ruby@puma: cluster worker 0: 567080 [backend]#567813) params.to_h.transform_keys(&:to_sym)
{:name=>"Device 1",
:device_id=>"D1234",
:scheduled_at=>"2022-10-19 18:30:08 +0000",
:location=>"office1",
:first_name=>"dsf",
:last_name=>"zdsfgdf",
:password=>"dsgdf",
:email=>"dsfgsd@sdfs.com"}
Activity
dentarg commentedon Oct 20, 2022
paramsis not a real hash, see https://github.com/sinatra/sinatra/blob/v3.0.2/lib/sinatra/indifferent_hash.rbsome more info in #1592
usern3 commentedon Oct 21, 2022
Okay I see now. I'm still confused as to why
params.transform_keys(&:to_sym)doesn't work though since IndifferentHash seems to have transform_keys methods?dentarg commentedon Oct 21, 2022
convert_keyalways converts keys to stringsusern3 commentedon Oct 21, 2022
ah gotcha okay thanks for clearing that up.
NobodysNightmare commentedon Nov 22, 2022
Looking at the timing you brought this up, did your code include a
selectorrejectcall before usingtransform_keysin the past?I was wondering the same (some code broke after an upgrade) and it turns out that these methods did return regular hashes before the upgrade (and thus
transform_keysworked) but return an indifferent hash after the upgrade. See #1711usern3 commentedon Nov 22, 2022
I don't recall using
selectorrejectpreviously. So, if you used one of those before it returned a regular ruby hash?NobodysNightmare commentedon Nov 22, 2022