-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python: add XINFO STREAM command #1816
Python: add XINFO STREAM command #1816
Conversation
37542ef
to
3b70d43
Compare
return Err((ErrorKind::TypeError, "Groups key not found").into()); | ||
}; | ||
|
||
if array.get(groups_index + 1).is_none() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we need it here, but you might want to add an overflow check here, in case groups_index is usize::MAX
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely a good callout, but I don't think it is needed. usize::MAX is 18_446_744_073_709_551_615
, but groups_index + 1 is always 18 with the current version of redis. For this to overflow, valkey would have to add enough fields in this array to boost that number over usize::MAX, which seems very unlikely.
*/ | ||
ExpectedReturnType::XInfoStreamFullReturnType => match value { | ||
Value::Map(_) => Ok(value), // Response is already in RESP3 format - no conversion needed | ||
Value::Array(mut array) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could probably refactor some of this code, since it's repetitive in some areas. We're essentially using the array like an association list, so we probably could write a (zero-cost) abstraction around this behaviour to make things a bit easier to reason about. Not a blocker, but something to think about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, not sure if we will get around to it in this PR but we'll see. I agree that we can probably do some refactoring here to improve things
|
||
if groups.is_empty() { | ||
let converted_response = convert_to_expected_type(Value::Array(array), Some(ExpectedReturnType::Map { | ||
key_type: &Some(ExpectedReturnType::BulkString), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
key_type: &Some(ExpectedReturnType::BulkString), | |
key_type: &Some(ExpectedReturnType::SimpleString), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand how it causes nested map[]
to convert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is covering the scenario where "groups" is empty, i.e. there are no groups for the stream. Usually the nested maps are inside of groups (each group needs to be converted to a map, and each consumer inside that group map needs to be converted to a map). But since groups is empty in this block there are no nested maps that we need to convert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see
So you just flat the recursion into a nested loops.
Maybe we need to rework it in the CompletableFuture
@@ -214,6 +214,7 @@ pub enum RequestType { | |||
XAutoClaim = 203, | |||
XInfoGroups = 204, | |||
XInfoConsumers = 205, | |||
XInfoStream = 207, | |||
Scan = 206, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this ordering is unacceptable!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lol 206 was stolen from me, it was either group the XInfo commands together but have weird numerical ordering or group them apart but have consistently increasing number values. I didn't want to change the scan numerical value to 207 because that could mess with other people's local code if they forget to rebuild after pulling this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could've kept the numbers while swapping the ordering 😆 - welp, too late.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree with having bulk strings as map keys in the response, but this probably should be updated for all related commands together.
LGTM
Yes. A cleanup task for both teams to make a conscious effort to refactor and cleanup typing. We have way too much code and quite a bit of hand-waving going on in this file. Something to address in the coming month(s). |
* Grab value conversion from Java draft PR * wip * wip * refactor value conversion wip * Make value_conversion build * Add value conversion test * Verified test values * Fix errors in test * RESP3 tests passing * Tests passing for RESP3, mypy passing * Update CHANGELOG, minor doc fix * Fix failing value conversion test * Clean up value_conversion.rs a bit * minor cleanup * Modify test to cover failing scenario * Python tests passing * Fix test function signatures * Fix failing pytest, cleanup value conversion comments * PR suggestions --------- Co-authored-by: Jonathan Louie <[email protected]>
Issue #, if available:
N/A
Description of changes:
https://redis.io/docs/latest/commands/xinfo-stream/
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.