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.
Implements #502 . Adds support for binary keys in MultiType. Specifically, this is needed for reading binary fields (keys) of HASH-es with HGETALL command.
The approach is to always store elements of multi in
multiarray, and evaluate corresponding map with string or/and binary keys when either is requested. This approach makes this class NOT thread safe, but it is not a really useful feature since under typical usage scenarios there won't be concurrent access. Hence, it's better to keep this class simple and not-thread-safe, and if the need to use it concurrently arises in some exotic use cases, then let the callers deal with it externally.NOTE: I had to decide whether to keep using un-ordered HashMap for binary keys too, or change both strMap and binMap to be LinkedHashMap. In fact, Redis preserves order of fields in HASH-es, and relevant commands like HKEYS, HVALS, HSCAN and HGETALL particularly, return values in their respective order. With this change, the existing method
MultiType#getKeys()will also preserve order, which was not the case due to usage of HashMap. Even though technically this is a change of behavior, it can not affect any existing users, as they were unable to rely on the order anyway prior to this change.