Add imapK and instrument helpers #772
Conversation
Add ways to transform instances of RedisCommands with regard to their effect type. This enables to work more easily with Kleisli-based effects or collect metrics like epimetheus-redis4cats does and breaks whenever new operations are added to redis4cats.
|
|
||
| implicit class InstrumentOps[F[_], K, V](val cmd: RedisCommands[F, K, V]) extends AnyVal { | ||
| def instrument(ff: F ~> F, includeTransactions: Boolean): RedisCommands[F, K, V] = { | ||
| if(includeTransactions) |
There was a problem hiding this comment.
I'm not entirely sure whether both use cases actually exist or whether an opinionated version would be sufficient. Maybe someone has more insights here (I'm not using transactions/pipelines)?
There was a problem hiding this comment.
Hey @ybasket , sorry to turn you down, but the code duplication of every Redis method is what we've been avoiding since the creation of this project.
I assume the liftK extension method is not sufficient for your use case? I'd be happy to accept imapK if we can get rid of all the duplication, as that's some heavy maintenance burden I would rather avoid.
If that isn't feasible, I would propose another repository for this functionality (e.g. profunktor-redis4cats-ops) with a different release cycle, which should work with package-private code.
Hey, no problem, I was aware of the risk this could happen. It's not that I like the repetition, it would just move some issues to a place where the solution is kept more in sync. I guess an
|
Add ways to transform instances of RedisCommands with regard to their effect type. This enables to work more easily with Kleisli-based effects or collect metrics like epimetheus-redis4cats does and breaks whenever new operations are added to redis4cats.