Kotlin Coroutine API

[sokomishalov]

Related issue: #1386

[mp911de]

Thank you for your pull request. This is an impressive contribution and we would like to include it.

For the implementation part, we typically keep all command implementations in a single support class to avoid an excessive number of classes.

I'm a bit confused why there are three variants, RedisSuspendableCommands.kt, RedisSuspendableAsyncCommands.kt, and RedisSuspendableReactiveCommands.kt. Having a singe suspendable API seems sufficient (RedisSuspendableCommands and segregated interfaces such as RedisSetSuspendableCommands, …).

I'm also missing the entry point, i.e. how to obtain suspendable commands from a Redis Connection. Finally, it would make also sense to provide a bit of documentation (simply drop an asciidoc file into src/main/asciidoc) to complete this PR.

[sokomishalov]

I'm a bit confused why there are three variants, RedisSuspendableCommands.kt, RedisSuspendableAsyncCommands.kt, and RedisSuspendableReactiveCommands.kt. Having a singe suspendable API seems sufficient (RedisSuspendableCommands and segregated interfaces such as RedisSetSuspendableCommands, …).

My first idea was just to add extensions to async and reactive APIs (spring approach btw), but it is impossible now without changing a method signature/name/scope. Although suspend functions have a different signature in bytecode (by adding the Continuation parameter) kotlin compiler cannot distinguish it from a member function in the source code. It could be fixed by adding some prefix to extensions (i.e. aPing()), but it makes API much worse imho.
So I decided to propose the common "suspendable" interface, which is implemented by wrapping reactive and async operations (and who knows maybe will have some independent and "native" implementation in the future). I think implementation should be generated too because of its simpleness (see KotlinCompilationFactory).
That's my point, which is arguable and not ideal maybe.

For the implementation part, we typically keep all command implementations in a single support class to avoid an excessive number of classes.

it was just simpler to generate and then just have one class that implements all segregated interfaces by delegating to the generated ones (see RedisSuspendableReactiveCommandsImpl and RedisSuspendableAsyncCommandsImpl). I can make generated implementations internal to prevent exposing them and confusing end-users. But if it's inappropriate I'll rework the generator for this or just move it to a single one.

I'm also missing the entry point, i.e. how to obtain suspendable commands from a Redis Connection

Totally forgot, will add it soon
I think suspendable API is useless for plain java users so it could be provided in "kotlinese" way - extensions for reactive and async commands.

val cmd1 = connection.reactive().asSuspendable()
val cmd2 = connection.async().asSuspendable()

Finally, it would make also sense to provide a bit of documentation (simply drop an asciidoc file into src/main/asciidoc) to complete this PR.

Absolutely

[mp911de]

Thanks. I'm going to take this pull request from here targeting the 6.0 RC2 release. Specifically, I'll keep only a single suspendable implementation based on top of the reactive API to avoid a maintenance hell. There's no actual reason to keep both implementations.

[mp911de]

Thanks a lot for your contribution.

That's merged and polished now. I removed all deprecated methods and StreamingChannel methods from the API. It doesn't make sense to ship deprecated commands on a new API. Also, it makes sense to provide Flow-based variants instead of StreamingChannel as StreamingChannel comes from a time where we had no reactive API.

I created a few tickets to polish up the code generator. Feel free to have a look if you want to contribute to Lettuce.

[sokomishalov]

That's great!
Sure, thank you too.