valkey
valkey copied to clipboard
valkey-io
[NEW] CONFIG GET should preserve input order or return sorted results
The problem/use-case that the feature addresses
When using CONFIG GET with multiple parameters, the returned key-value pairs come back in an unspecified order. This makes it harder to match results to inputs in scripts or tools, complicates automated validation, and makes config diffs less predictable.
Description of the feature CONFIG GET should return results in the same order as the requested parameters. Alternatively, it could return the results sorted alphabetically by parameter name for predictability.
Alternatives you've considered
- Post-processing the results in client code to re-order them. This is error-prone and unnecessary overhead.
- Using separate CONFIG GET calls per parameter, which adds round-trip latency.
Additional information Other commands already preserve order (eg. CLUSTER SLOTS,)
I fully agree about the suggestion.
some minor comment:
CONFIG GET should return results in the same order as the requested parameters. Alternatively, it could return the results sorted alphabetically by parameter name for predictability.
I would suggest the important part is that in case arguments WERE provided is MUST return the result in the same order of the provided parameters In case NO argument was provided it will return the list alphabetically ordered (or not - not sure if that makes any difference for clients...)
We did have a conversation about this at some point, since you can do something like config get a* *b, there is really no defined ordering if something matches both. You are intended to load it as a map and then parse it, but you are right that it really makes no sense to do CONFIG GET A B and have it returned in B and then A. I guess I would vote for a sorted output.
I would suggest the important part is that in case arguments WERE provided is MUST return the result in the same order of the provided parameters
We want to avoid duplicates. So if you do config get A* A it should only return A once, even though it's specified as the second argument.
Using separate CONFIG GET calls per parameter, which adds round-trip latency.
Multi-exec would remove the round-trip latency.
Using separate CONFIG GET calls per parameter, which adds round-trip latency.
Multi-exec would remove the round-trip latency.
Eh, there's no extra roundtrip latency if you just don't wait for reply before you send the next command (aka pipelining). Multi-exec has nothing to do with it, except it makes it atomic.
I vote for sorted output.
