The problem/use-case that the feature addresses

In a single atomic operation, we would like: 1. The return value of SET to represent whether the value actually changed 2. To be able to optionally update a key's TTL only if the saved value changes

The first, we would like in order to keep a count of keys whose values changed. The second, we would like in order to choose whether to update the key's TTL based on whether the value is changed.

Description of the feature

Two new options, RVC and UTVC, would be added to the SET command. They would be compatible with the XX option but not the NX option.

RVC - Return OK only if value changed

If SET key value [ttl args] RVC is called, then: 1. The return value will be (nil) if the key already exists and the saved value is already equal to value. 2. However, TTL parameters will still be used, updating the TTL as specified.

UTVC - Update TTL only if value changed

If SET key value [ttl args] UTVC is called, then: 1. The return value will be (nil) if the key already exists and the saved value is already equal to value. 2. In that scenario, all TTL arguments will be ignored if the saved value is already equal to value. 3. If XX is combined with UTVC, then the key will not be set if it does not yet exist.

Alternatives you've considered

We're currently using a Lua script to simulate this functionality, but it would be better to have it all in a single atomic operation.

Additional information

RVC is similar to the CH option already present for the ZADD command.

Comment From: alexronke-channeladvisor

I am interested in developing this option, assuming it is acceptable to the team.

Comment From: alexronke-channeladvisor

I'm making some revisions to the feature request, as I realized I need to cover one other use case.

Comment From: oranagra

@alexronke-channeladvisor sorry for the delay (issue came in when we were already finalizing redis 7.0, so it couldn't be a candidate for that release, and we were busy with it and didn't have time to get into the details)

These features seem kinda specific, so i'm not sure that we want to add that logic to redis as is. i.e. if you can convince us that these two features are commonly needed and would help many people, then they're candidates for build in features for redis. otherwise, they should be done by either Lua or modules.

@itamarhaber have you seen any similar requests or use cases that could benefit from these?

Comment From: itamarhaber

I think these are related to the CAS/CAD discussions we had in the past (e.g. https://github.com/redis/redis/pull/8361 and https://groups.google.com/forum/#!topic/redis-db/a4zK2k1Lefo) - maybe it is time to revisit the topic for upcoming versions. That said, I share @oranagra's opinion about the specificness of the proposal.