-
Notifications
You must be signed in to change notification settings - Fork 23.9k
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
Add NX/XX/GT/LT options to EXPIRE command group #2795
Conversation
+1, this would be handy |
@sunng87 like this. Can you rebase and add a test. |
Definitely useful for saving a 7-liner scriprt - I'm for it. My only beef is the naming - |
I agree this would be nice to have. |
No problem. Let me catch up |
Signed-off-by: Ning Sun <[email protected]>
Signed-off-by: Ning Sun <[email protected]>
These two tasks can be done via pipeline as a workaround (pipelining multiple |
Signed-off-by: Ning Sun <[email protected]>
@sunng87 you mean that LT would fix your problem the same way that NX does, but there are probably use cases that will benefit from one and not from the other. |
I agree and there are always possibilities. But before we have real scenario I would suggest to keep the code simple and open for new options. |
@oranagra I think that having smarter |
The patch is ready for review. |
I think we wanna take this opportunity to add all the other useful options. |
|
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.
thank you for the efforts.
i added a few comments. some are suggestion for improvements, others are open for discussion, let me know what you think.
src/expire.c
Outdated
if (flag & FLAG_NX) { | ||
current_expire = getExpire(c->db, key); | ||
if (current_expire != -1) { | ||
addReply(c,shared.czero); |
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.
the docs say that 0
is returned when the key doesn't exist.
i suppose it makes sense to at least let the caller distinguish between non-existing key and a skipped operation due to flag.
one option could have been to return -1
in these cases, but considering that this is inconsistent with the -1
and -2
values returned by the TTL command, maybe that's not a wise idea.
maybe like the linked issue asks for, we better add a way to just return the TTL.
it's true that the user can pipeline a TTL command right after this one, but i suppose it'll be more convenient to let them use this in one go.
I suggest to add a GET
flag, which will change the return value from 0/1 to the same return value TTL command group has (see ttlGenericCommand
). i.e. it would be relative/absolute and ms/sec depending on the EXPIRE variant that was used, and we'll have to also return -2 and -1 in the appropriate places.
p.s. another wild idea is to also support an INCR flag (for the non-absolute expire variants, when basetime
is not 0), in which case we increment the existing expiration time (similarly to the ZADD feature).
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 still suggest not to use the return value of EXPIRE
commands for TTL. It introduces additional complexity for various clients to distinguish return code and value for this write operation, that defined by an optional flag.
And also I think returning 0
makes sense for this new scenario. We can extend its meaning along with these new features. The 0
means nothing changed with this write operation, it can be a key not exist or the operation is skipped.
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.
ok. we can stop here. already a big step forward.
GET and INCR arguments can be added later if we wish (nothing here that prevents that)
Signed-off-by: Ning Sun <[email protected]>
Signed-off-by: Ning Sun <[email protected]>
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.
LGTM.. few minor suggestions for improvement.
@oranagra All issues resolved. Thanks for your patient and great suggestions. |
@sunng87 thanks.. |
@sunng87 please merge my indentation fixes suggestions (it seems this PR doesn't let me edit the code) |
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.
LGTM, added a few minor typo/formatting comments.
4bca6c0
to
ff3d321
Compare
Signed-off-by: Ning Sun <[email protected]>
Doc changes created at redis/redis-doc#1613 |
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.
API and code LGTM.
Add NX, XX, GT, and LT flags to EXPIRE, PEXPIRE, EXPIREAT, PEXAPIREAT. - NX - only modify the TTL if no TTL is currently set - XX - only modify the TTL if there is a TTL currently set - GT - only increase the TTL (considering non-volatile keys as infinite expire time) - LT - only decrease the TTL (considering non-volatile keys as infinite expire time) return value of the command is 0 when the operation was skipped due to one of these flags. Signed-off-by: Ning Sun <[email protected]>
Add NX, XX, GT, and LT flags to EXPIRE, PEXPIRE, EXPIREAT, PEXAPIREAT.
return value of the command is 0 when the operation was skipped due to one of these flags.
Just some quick work to add an
NX
option to expire commands. This allows expiration to be set for only once, just like setnx. In our application, we have some zsets and hashes that update frequently, but expire at a fixed time defined at its creation.Searched issue history, I also found some others who had similar requirements: #1840
This is just the first commit. If you think it's OK I will add docs and tests for this feature. Thanks!
EDIT: spelling