Draft: Client side caching #1001
Conversation
a-khakimov
force-pushed
the
client_side_caching
branch
2 times, most recently
from
7ca2e86 to
7b85754
Compare
a-khakimov
force-pushed
the
client_side_caching
branch
from
7b85754 to
29e7129
Compare
| object ClientSideCaching { | ||
|
|
||
| def make[F[_]: Async, K, V]( | ||
| connection: StatefulRedisConnection[K, V], |
There was a problem hiding this comment.
|
|
||
| def make[F[_]: Async, K, V]( | ||
| connection: StatefulRedisConnection[K, V], | ||
| args: TrackingArgs, |
There was a problem hiding this comment.
the convention in this lib , is to create a scala api for the java pojo's . i.e.
| args: TrackingArgs, | ||
| cacheAccessor: CacheAccessor[F, K, V] | ||
| ): Resource[F, JCacheFrontend[K, V]] = | ||
| TxExecutor.make[F].flatMap { redisExecutor => |
There was a problem hiding this comment.
putting aside the changes to TxExecutor, we should create a facade for CacheFrontend similar to CacheAccessor and not require a Dispatcher and unsafeRun
| def eval[A](fa: F[A]): F[A] | ||
| def start[A](fa: F[A]): F[Fiber[F, Throwable, A]] | ||
| def liftK[G[_]: Async]: TxExecutor[G] | ||
| def liftK[G[_]: Async: Dispatcher]: TxExecutor[G] |
There was a problem hiding this comment.
this would be a breaking change as it adds additional parameters.
I dont think TxExecutor is the right place for this, it is meant for Redis transactions
There was a problem hiding this comment.
I would add that Dispatcher is not meant to be used as a typeclass, i.e. it should be passed explicitly
|
In general , I don't like Lettuce's implementation that forces a separate interface for cached values vs uncached. |
3 participants
This is a draft implementation of Client Side Caching - #998.
This is roughly how I envision the interface — I’ll finish it soon and add usage examples.
Feel free to take a look; any questions or suggestions are very welcome!