-
Notifications
You must be signed in to change notification settings - Fork 683
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
GEODE-9952: Support LSET Command #7396
GEODE-9952: Support LSET Command #7396
Conversation
This pull request introduces 2 alerts when merging f4155e4 into 1fc35af - view on LGTM.com new alerts:
|
...redis/src/main/java/org/apache/geode/redis/internal/commands/executor/list/LSetExecutor.java
Outdated
Show resolved
Hide resolved
geode-for-redis/src/main/java/org/apache/geode/redis/internal/data/NullRedisList.java
Outdated
Show resolved
Hide resolved
...redis/src/main/java/org/apache/geode/redis/internal/commands/executor/list/LSetExecutor.java
Outdated
Show resolved
Hide resolved
...java/org/apache/geode/redis/internal/commands/executor/list/AbstractLSetIntegrationTest.java
Show resolved
Hide resolved
Already discussed this in Slack, but LSET should be added to the list of supported commands in the docs file |
This pull request introduces 4 alerts when merging b70d700 into 45cbe7f - view on LGTM.com new alerts:
|
...redis/src/main/java/org/apache/geode/redis/internal/commands/executor/list/LSetExecutor.java
Outdated
Show resolved
Hide resolved
geode-for-redis/src/main/java/org/apache/geode/redis/internal/data/RedisList.java
Outdated
Show resolved
Hide resolved
.../apache/geode/redis/internal/commands/executor/server/AbstractHitsMissesIntegrationTest.java
Outdated
Show resolved
Hide resolved
geode-for-redis/src/main/java/org/apache/geode/redis/internal/RedisConstants.java
Outdated
Show resolved
Hide resolved
...redis/src/main/java/org/apache/geode/redis/internal/commands/executor/list/LSetExecutor.java
Show resolved
Hide resolved
geode-for-redis/src/main/java/org/apache/geode/redis/internal/data/NullRedisList.java
Outdated
Show resolved
Hide resolved
...java/org/apache/geode/redis/internal/commands/executor/list/AbstractLSetIntegrationTest.java
Outdated
Show resolved
Hide resolved
...java/org/apache/geode/redis/internal/commands/executor/list/AbstractLSetIntegrationTest.java
Show resolved
Hide resolved
...java/org/apache/geode/redis/internal/commands/executor/list/AbstractLSetIntegrationTest.java
Outdated
Show resolved
Hide resolved
In addition to the changes requested above, we should add a DUnit test for LSET, specifically one where we call LSET then crash the primary, then assert that the contents of the secondary matches what we expect after failing over, to make sure that deltas are being propagated and applied correctly. |
geode-for-redis/src/main/java/org/apache/geode/redis/internal/data/RedisList.java
Outdated
Show resolved
Hide resolved
c8da0eb
to
155cd7b
Compare
904b4c7
to
8fe4d36
Compare
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.
Couple minor bits, otherwise seems legit
...java/org/apache/geode/redis/internal/commands/executor/list/AbstractLSetIntegrationTest.java
Show resolved
Hide resolved
geode-for-redis/src/main/java/org/apache/geode/redis/internal/data/NullRedisList.java
Outdated
Show resolved
Hide resolved
List<byte[]> commandElements = command.getProcessedCommand(); | ||
RedisKey key = command.getKey(); | ||
|
||
return context.listLockedExecute(key, false, list -> { |
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.
Sorry, I thought I had commented here but now realize I hadn't. A few days ago there was a discussion (but I think you were out) that we don't need to support multiple command error conditions in the same 'order' that redis does - i.e. wrong key AND wrong index (say an invalid number) produces errors in the same order as redis. (So we can remove tests that check for this). This will avoid the need for checking existence here and then you can also pull the number check out of this block. Ultimately it simplifies this code and makes it more consistent with our other code. You'd end up with what we usually have, namely something like:
return context.listLockedExecute(key, false, list -> list.lset(region, key, index, value);
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.
We should still keep the NumberFormatException
check (and relevant test for that) but it just doesn't need to be inside the listLockedExecute
call.
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.
We still need to keep the NumberFormatException
in LSetExecutor
.
Implements the LSET command as described by the Redis documentation. LSET key index newValue ex. LSET key 1 "newValue" The LSET command sets the list element at the given index to the specified new value. If the value is negative, it wraps around. If the index, after being adjusted for negative values, is out of bounds, the RedisResponse will be an index out of bounds error. If the key does not exist then it will not be created and a key does not exist error will be returned. The command may return: - OK - ERR index out of bounds - ERR no such key
5faa74d
to
f3f02e1
Compare
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.
Nice! Thanks for your changes.
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.
Looks good!
Implements the LSET command as described by the Redis documentation. LSET key index newValue ex. LSET key 1 "newValue" The LSET command sets the list element at the given index to the specified new value. If the value is negative, it wraps around. If the index, after being adjusted for negative values, is out of bounds, the RedisResponse will be an index out of bounds error. If the key does not exist then it will not be created and a key does not exist error will be returned. The command may return: - OK - ERR index out of bounds - ERR no such key
Implements the LSET command as described by the Redis documentation.
LSET key index newValue
ex. LSET key 1 "newValue"
The LSET command sets the list element at the given index to the
specified new value.
If the value is negative, it wraps around.
If the index, after being adjusted for negative values, is out of
bounds, the RedisResponse will be an index out of bounds error.
If the key does not exist then it will not be created and a key does not
exist error will be returned.
The command may return:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop
)?Is your initial contribution a single, squashed commit?
Does
gradlew build
run cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?