RedisShards.scala (src/main/scala/com/redis/cluster/RedisShards.scala) fails to override some methods from its parent class RedisCommand, making replacing RedisCommand with RedisShards error-prone in ways that are hard to diagnose.
Specifically, we found that RedisShards fails to override the (now-deprecated) call def set(key: Any, value: Any, nxxx: Any, expx: Any, time: Long). It should.
Also, evalBulk should be overridden to either throw an exception or to throw an exception when given more than a single key. (and to then work when given a single key)
There may be other methods that RedisShards fails to override; for safety (to keep from silently falling back to single-sharded code), a simple fix is to override connect in RedisShards to throw an error. E.g.:
override def connect: Boolean = throw new UnsupportedOperationException("Unsupported sharded operation");
At least then such fall-back behavior will be easy to diagnose.
RedisShards.scala (
src/main/scala/com/redis/cluster/RedisShards.scala
) fails to override some methods from its parent classRedisCommand
, making replacingRedisCommand
withRedisShards
error-prone in ways that are hard to diagnose.Specifically, we found that RedisShards fails to override the (now-deprecated) call
def set(key: Any, value: Any, nxxx: Any, expx: Any, time: Long)
. It should.Also,
evalBulk
should be overridden to either throw an exception or to throw an exception when given more than a single key. (and to then work when given a single key)There may be other methods that RedisShards fails to override; for safety (to keep from silently falling back to single-sharded code), a simple fix is to override
connect
inRedisShards
to throw an error. E.g.:At least then such fall-back behavior will be easy to diagnose.