Redis: Regarding client.Multi deprecation

[sammy007]

I noticed that client.Multi marked in docs as deprecated, correct me if I am wrong, but isn't it useful when you need to run a bunch of commands in "all or nothing" way and won't maintain consistency?

[vmihailenco]

Docs suggest that you use https://godoc.org/gopkg.in/redis.v3#Client.Watch instead, which provides more idiomatic API (look at example).

[sammy007]

I understand Watch, but what if I don't wanna watch and just execute a bunch of updates? As far as I know plain .Multi provides "all or nothing" insurance without watch and I am concerned about deprecation. Hope it will be there in next versions. Obviously Watch is must have for consistency, but multi is still have it's use.

[vmihailenco]

AFAIK Redis transactions don't provide "all or nothing" behaviour http://redis.io/topics/transactions

Errors happening after EXEC instead are not handled in a special way: all the other commands will be executed even if some command fails during the transaction.

So you should use Pipeline if you don't need Watch.

[sammy007]

You should be very lucky to get failed commands after exec, at least they won't be executed in case of connection failure. The point is that if redis allows something, client should allow too. Please let .multi be there.

[vmihailenco]

The idea is to "force" users to use Pipeline instead of Multi, because:

• you get same guarantees as with Multi (pipelined commands are sent using single write)
• Pipeline is much cheaper for use since connection is immediately returned to the pool

And so far I don't see any drawbacks...

[vincentcr]

the drawback, of course, is that it's not really your place to decide which features people ought to use. if it's not deprecated by redis, it belongs in the client.

[vmihailenco]

Old API is going away in v4, but you can get old behaviour by using watch without any keys, e.g. tx, err := client.Watch().

[sammy007]

What is replacement for that in v5?

[vmihailenco]

You could try https://godoc.org/gopkg.in/redis.v5#Client.TxPipeline

[ellseworth]

If I'm correct in dealing with Client.Pipline/Client.TxPipline, the problem is that you can't control how it goes in step by step manner. By using Client.Pipline/Client.TxPipline I need to define set of commands, try to execute it with the pipliner and next a big bunch of code starts to determine, what command from the set went wrong.
I would like to execute some sequence of commands in transaction without watching any keys, but reling that some of the commands redis will execute as atomic, and I can check how that commands will execute one by one. In that case if some command from the set will go wrong, I just discard transaction immeditelly and log the place, where it happend, that make it easier to figure out, what is the reason of the failure

[sammy007]

The removal is still a total nonsense for me. No need to "force" users to do something because you think it's better. There is redis.multi, clients should be able to use it if they need it.

[vmihailenco]

@ellseworth Watch can be called without any keys to watch - https://godoc.org/github.com/go-redis/redis#Client.Watch

Multi is long gone - I already forgot the details. If you think API does not cover some use case - please open new issue with some examples.