Support for GET option in SET command

[mikewacker]

https://www.javadoc.io/doc/redis.clients/jedis/latest/redis/clients/jedis/params/SetParams.html

There's no get() method for SetParams.

---

Here's a command to motivate this feature request:

SET some:key 1 NX GET

There's a couple reasons why client.getSet() isn't a viable workaround (where client is of type JedisPooled):

• It doesn't support, e.g., EX or NX options.
• It's a deprecated method.

[ggivo]

Redis 6.2 supports a GET option to retrieve the old value before the new value was set. We should introduce a new method to allow for returning values. See also https://redis.io/commands/set

[ggivo]

JedisPooled already provides

  String setGet(String key, String value, SetParams params);

  byte[] setGet(byte[] key, byte[] value, SetParams params);

Both methods delegate to SET command with an added GET parameter

Support for setGet added with #3134
Deprecated GETSET resolved with #3768

[mikewacker]

Sorry for the late response, @ggivo. This works, though it does violate POLA.

If you're translating a SET command with a GET option to a JedisPooled call:

• the least astonishing thing would be to call set() with SetParams.
• setGet() (not to be confused with getSet()) works, but it's odd to call a separate method here, one whose name doesn't correspond to a Redis command.

A minor POLA violation probably doesn't warrant reopening the issue, but I wanted to flag the POLA concern nonetheless.

[ggivo]

@mikewacker
I see your point, and your observations are correct. Thanks for rising the issue.
Looking at the history of #3134, it aims to resolve an issue when using GET parameters and using the binary version of set () in a non-breaking way. Since the signature of the binary set() was already returning String and it would be a breaking change to change it to byte[], new setGet methods were introduced as a shorthand for GET parameter.
Don't see an easy way of resolving the POLE concerns against set without introducing a breaking change.