Add SETNE

[erikdubbelboer]

Add command to only set a value when it's different than the current value. This is useful when listening for changes and you don't want to be notified when a value doesn't change.

This native command is about 3 times faster than using a lua script and is only a few new lines.

See: https://www.reddit.com/r/redis/comments/6vry8x/proposed_new_command_setne_set_if_not_equal/

[masterclock]

what's the progress of this PR?

[slayerulan]

Any update regarding this PR?

[GeoffreyPlitt]

+1 Really want this.

[kristoff-it]

Hi, I quickly wrote an implementation of this command as a module.
You can find the source code here:
https://github.com/kristoff-it/redis-setne

If you don't know / care about Zig, just download a pre-compiled dynamic library from the Releases section.

[kinkey]

What is the status of this PR? Thanks in advance.

[erikdubbelboer]

I could rebase it on master if there was a chance of it being merged. Buf after more thant 2 years I doubt it will be.

[yoav-steinberg]

The pros here are mostly performance related since there's an easy solution using scripting.
The cons are that this might be too specific for string set command and scripting can be used.
@itamarhaber @oranagra WDYT?
In any case I suggest we handle this or close it since it's not a big issue and the PR is ready.

[itamarhaber]

I think if this is added, instead of a new string command, SETs syntax can be added with an NE flag.

I don't think we should add a new flag though. If a SET doesn't modify the data, did it really happen? Assuming nothing's changed (i.e. also TTL is the same), should an event be generated or even a replication entry for that matter?

[madolson]

Another interesting case that comes to mind is client side caching, it would be an optimization to not invalidate a key if the value didn't change.

Idk though, LUA seems like the right approach here to me, this seems close to CAS which we've also been hesitant to implement. I suppose I would vote to close this, but don't feel strongly.

[yoav-steinberg]

I don't think we should add a new flag though. If a SET doesn't modify the data, did it really happen? Assuming nothing's changed (i.e. also TTL is the same), should an event be generated or even a replication entry for that matter?

The problem with treating this as just a SET optimization is:

• This might be considered a breaking change since in the past we did send notifications on this "nop".
• There's a serious performance issue here: doing the extra memcmp before each memcpy will definitely make SET slower.

@madolson I'm marking to be closed, as I think this can be treated as a special case of SETCAS (#8361) and we should continue discussion there. I'll reference this ticket there.

[motz0815]

The problem with treating this as just a SET optimization is:

* This might be considered a breaking change since in the past we did send notifications on this "nop".

* There's a serious performance issue here: doing the extra `memcmp` before each `memcpy` will definitely make `SET` slower.

@madolson I'm marking to be closed, as I think this can be treated as a special case of SETCAS (#8361) and we should continue discussion there. I'll reference this ticket there.

Wouldn't that be even slower than just adding a new command that does that all by itself?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}