SET command supports EX and PX parameters to configure the key TTL. (http://redis.io/commands/SET)

It would be nice if the GETSET command also support those parameters, this way we could SET and configure the TTL in the same command. (http://redis.io/commands/GETSET)

What do you guys think about it? @antirez

Comment From: mattsta

That looks like a safe change since it only adds optional arguments.

Someone is fixing code for SET [EX|PX] at https://github.com/antirez/redis/pull/2159 — you could take their improved SET argument code, work it into the GETSET command processing, then open a PR with the improvement for GETSET!

Comment From: nykolaslima

Ok @mattsta. I'll implement it and open a PR.

Thank you for your considerations.

Comment From: nykolaslima

@mattsta @antirez can we move on with this feature implementation? Looks like an issue that people still have. If you agree I could implement it.

Comment From: itamarhaber

+1 for the feature.

Comment From: snlamm

+1

Comment From: akshayrao14

+1

Comment From: paolodenti

+1

Comment From: bulbul-ismail

+1

Comment From: mikolaje

+10086

Comment From: anotherGoogleFan

+1

Comment From: nahuely

+1

Comment From: thushw

+1

Comment From: dmi3zkm

+1

Comment From: lannka

+1

Comment From: oranagra

@nykolaslima are you interested in picking this up again?

Comment From: nykolaslima

Hi @oranagra , sure! I'll try to do it today and open a PR. I'll let you know

Comment From: oranagra

@nykolaslima no need for another PR (we already have two). We just need to pick a design and refresh / rebase the existing PR. I've reviewed all the correspondence in the issue and two PRs, and i think the SET GT approach is best, but i'd like you to review again and tell me if you feel otherwise.

I did ask some client library maintainers if they see any problem with SET sometimes returning a status result and other times returning a value, and no one indicated that it's a problem.

Comment From: nykolaslima

@oranagra the main drawback of SET GT approach is the two different return types: status by default and old value whenGT option. Choosing this approach would allow us to deprecate the GETSET command and stick with just one command.

Have you talked with statically typed language clients, such as Java, in order to check if this change will not break them? There is a long time since I didn't work with the Java client but I think it would be a nice check to have.

Comment From: oranagra

@jruaux @gkorland what do you think of the possibility of SET command having a GT argument that will cause it to return a value (like GETSET) rather than a status response? Do you see any problem with the Java client support for that?

Comment From: gkorland

Jedis can handle it, it won't break the existing set() since it doesn't send GT

Comment From: jruaux

I believe the same is true for Lettuce. Support for GT arg will need to be a different method returning a value instead of status.

Comment From: nykolaslima

@oranagra so let's move forward with the current solution (set with GT parameter)? You giving me a green light I can update the code

Comment From: oranagra

So for Redis, the cleanest way to handle it is to add the GT argument to the SET command, but for some client libraries, a new method must be added with a different return type, and that may possibly lead to confusion among users (mismatch between Redis's documentation and the client library documentation). I think this may be acceptable, but i'd like to hear opinions of the rest of the @redis/core-team.

Comment From: nykolaslima

Hi @oranagra , I understand your point. Let's wait for some feedback. It would be nice if people could not take too long to respond to it, since the issue is open since 2015 hahaha

Comment From: yossigo

@oranagra I also tend to think there's no problem here. Less opinionated clients (e.g. hiredis) don't make any assumptions about the return types and basically delegate this responsibility to the user. The more opinionated clients would anyway need to design GT support and will do that in a way that makes sense, is backwards compatible, etc.

Comment From: oranagra

@nykolaslima please go ahead (revive #2387 close the other PR).

Comment From: nykolaslima

Awesome! I will do it and let you know

Comment From: oranagra

@nykolaslima i think we should change GT to GET, it would be a lot clearer to the user. maybe in the past GT would make more sense by matching XX and NX, but today we already have KEEPTTL too.

Comment From: nykolaslima

@nykolaslima i think we should change GT to GET, it would be a lot clearer to the user. maybe in the past GT would make more sense by matching XX and NX, but today we already have KEEPTTL too.

Sure, no problem.