Implement transactions API

[mijicd]

Extracted from this comment authored by @regis-leray.

Commands

• [ ] DISCARD Discard all commands issued after MULTI
• [ ] EXEC Execute all commands issued after MULTI
• [ ] MULTI Mark the start of a transaction block
• [ ] UNWATCH Forget about all watched keys
• [ ] WATCH key [key ...] Watch the given keys to determine execution of the MULTI/EXEC block

Tips

• Define the API in zio.redis.api.
• Command-specific options should be defined in zio.redis.options.
• Additional inputs and outputs can be defined in zio.redis.Input and zio.redis.Output, respectively.
• Redis API evolves, therefore the commands listed above might be slightly changed. Double check the official docs before starting with implementation.
• Use telnet to understand command protocol details.
• Write inputs and outputs tests in zio.redis.InputSpec and zio.redis.OutputSpec, respectively.
• Write integration tests by expanding the zio.redis.ApiSpec.
• If you feel that the pull request size is growing out of control, feel free to split it but make sure to link this issue in each of the related PRs.

[mijicd]

Redis transaction API consists of two groups of commands:

• transactions (MULTI, EXEC, DISCARD)
• optimistic locking (WATCH, UNWATCH)

The latter can be (relatively) easily implemented via the existing primitives, while the former requires more attention.

There are a few things to keep in mind:

• "group" transaction commands
• handle intermediate results
• consider having a separate connection for blocking operations (this is a general thing to evaluate, and we can and should deal with it later)

With that in mind, here's the rough idea for a primitive that we could use to represent transactions:

sealed trait RedisTransaction[+Out] {
  def commit: ZIO[RedisExecutor, RedisError, Out]
  // zip operators
} 

object RedisTransaction {
  final case class Single[In, Out](command: RedisCommand[In, Out], in: In) extends RedisTransaction[Out]

  final case class Zip[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[(A, B)]

  final case class ZipLeft[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[A]

  final case class ZipRight[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[B]
}

Note that this API forces user to be explicit about transaction boundaries. Internally, its "interpreter" would take care of all protocol details, e.g., calling commit would build a MULTI ... EXEC block at one point.

@anovakovic01 please take a look and let me know if you have any questions about it. Also, don't take this design as absolute truth - as said, it's just a rough idea.

[anovakovic01]

@mijicd Thanks for the instructions. I think that I've understood the base idea. Draft PR will be sent as soon as I sketch something.

[barthorre]

Anyone still working on this?

[mijicd]

@anovakovic01 is, he can share the current state, and perhaps you could pair up.

[barthorre]

Would be happy to assist where I can!

[anovakovic01]

@barthorre Sorry for waiting for an update this long. I'm still working on this one, should send a draft PR soon. It should introduce a single abstraction that will unify both transactions and the regular commands. When API is defined we'll need to update the executor to be able to process transactions. Help will be needed on that part.