Skip to content
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

Merged

Conversation

nonbinaryprogrammer
Copy link
Contributor

@nonbinaryprogrammer nonbinaryprogrammer commented Feb 25, 2022

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

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?

@lgtm-com
Copy link

lgtm-com bot commented Feb 25, 2022

This pull request introduces 2 alerts when merging f4155e4 into 1fc35af - view on LGTM.com

new alerts:

  • 2 for Spurious Javadoc @param tags

@ezoerner
Copy link
Contributor

ezoerner commented Feb 25, 2022

Already discussed this in Slack, but LSET should be added to the list of supported commands in the docs file

@lgtm-com
Copy link

lgtm-com bot commented Feb 25, 2022

This pull request introduces 4 alerts when merging b70d700 into 45cbe7f - view on LGTM.com

new alerts:

  • 4 for Spurious Javadoc @param tags

@DonalEvans
Copy link
Contributor

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.

Copy link
Contributor

@ringles ringles left a 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

List<byte[]> commandElements = command.getProcessedCommand();
RedisKey key = command.getKey();

return context.listLockedExecute(key, false, list -> {
Copy link
Contributor

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);

Copy link
Contributor

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.

Copy link
Contributor

@jdeppe-pivotal jdeppe-pivotal left a 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
Copy link
Contributor

@jdeppe-pivotal jdeppe-pivotal left a 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.

Copy link
Contributor

@ringles ringles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@nonbinaryprogrammer nonbinaryprogrammer merged commit 669149d into apache:develop Mar 18, 2022
@nonbinaryprogrammer nonbinaryprogrammer deleted the GEODE-9952-LSET branch March 18, 2022 17:02
Kris-10-0 pushed a commit to Kris-10-0/geode that referenced this pull request Mar 18, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
redis Issues related to the geode-for-redis module
Projects
None yet
6 participants