You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I understand Oj.load supports a :symbol_keys option to force creating symbol keys in the output hashes. But it seems like most JSON parsers do the same thing with a :symbolize_keys option, and multi_jsonspecifies that I have to use it to get symbol keys.
The sidekiq library in turn depends on this option to parse json to hashes with keys explicitly typecasted to strings. But I have configured oj to use symbol_keys: true by default, so it spits symbols instead and doesn't care about a :symbolize_keys option.
So the question is: wouldn't it be appropriate to make a synonym option :symbolize_keys to the already existing option :symbol_keys for compatibility with other libraries?
The text was updated successfully, but these errors were encountered:
Sorry, just found that multi_json already has a workaround for this. It just doesn't work for me because I'm trying to override a true default from Oj.default_options with a false value. I'll submit an issue to multi_json then.
Hello.
As far as I understand
Oj.load
supports a:symbol_keys
option to force creating symbol keys in the output hashes. But it seems like most JSON parsers do the same thing with a:symbolize_keys
option, andmulti_json
specifies that I have to use it to get symbol keys.The
sidekiq
library in turn depends on this option to parse json to hashes with keys explicitly typecasted to strings. But I have configuredoj
to usesymbol_keys: true
by default, so it spits symbols instead and doesn't care about a:symbolize_keys
option.So the question is: wouldn't it be appropriate to make a synonym option
:symbolize_keys
to the already existing option:symbol_keys
for compatibility with other libraries?The text was updated successfully, but these errors were encountered: