Conversation
I don't follow this. Is the issue that |
This would only cause the symbol key value to be used instead of the def [](key)
load_for_read!
fetch(key.to_s, super(key))
endThat could return a |
There was a problem hiding this comment.
This will not nuke the symbol keys if they exist, right?
There was a problem hiding this comment.
If this is a hash with indiff access, we probably want deep_stringify_keys.
There was a problem hiding this comment.
This will not nuke the symbol keys if they exist, right?
Correct, but since we prefer string keys on access, I don't think it should matter.
If this is a hash with indiff access, we probably want deep_stringify_keys.
We don't convert nested hashes to have string keys on access, so I do not think we should deep stringify. This is inline with not allowing symbols (or hashes with symbols) to be stored in the session object and the same principle followed as access within flash objects (keys can be symbols, but you cant store hashes w/ symbols).
3 participants
After #64, session objects accessed with a symbol would no longer be able to return false due to the return logic and would return nil. This explicitly checks for a nil return instead of something falsey.
This also updates
updateto stringify keys before the update.