Common interface for binary clustered and non-clustered redis needed

[greenrd]

In 2.9.0, RedisCommands is implemented by both Jedis and JedisCluster, but does not include the binary versions of the commands, and there appears to be no common interface which includes binary versions of the commands shared between Jedis and JedisCluster.

[sazzad16]

@greenrd There is no RedisCommands. Could you please clarify which interface you're talking about?

[greenrd]

@sazzad16 Sorry, it was a typo. I meant JedisCommands.

[HeartSaVioR]

We've discussed about this before while adding interface for JedisCluster.
The issue is that JedisCluster doesn't support all the commands. If we apply origin interfaces to (Binary)JedisCluster, some methods in JedisCluster should be implemented as throwing UnsupportedException.

While in discussion we thought it is bad, so we adopt separate interfaces in JedisCluster, but I have been thinking I might be wrong. Unifying interface might have more worth than avoiding UnsupportedException. I would like to hear opinions again.

@marcosnils @sazzad16 @greenrd @mp911de (as you thumb up :) )

[mp911de]

Having a common interface with commands shared between Redis Cluster and Redis Standalone (Master/Slave) is beneficial as it does no further distinction in client code. Right now, we need to operate either on Jedis or JedisCluster and make that distinction in the code.

I propose to design an interface that:

1. Summarizes all data-type specific command interfaces (keys, string, lists, Lua, …).
2. Does not expose cluster commands (I made that mistake with RedisClusterCommands which is also used for Redis Standalone in Lettuce).
3. Does not expose transactional commands or standalone commands (like MULTI and SELECT).
4. Has no state (i.e. not extending Closeable and such, the API is intended for command usage, not lifecycle control).

You end up with an interface (well, two, one for byte arrays and one for strings) that exposes just the intersection of commands supported by Redis Standalone and Cluster. That interface can be the new API implemented by Jedis and JedisCluster and should be promoted in code samples for broad adoption. Not sure about transactions and pipelining right now, that can be the next step.

Does this make sense?

[richard-senior]

All, I'd like to second this.
We are a very large corporate. We're using an Amazon provided Redis instance currently which we have essentially maxed. We want to move to a later version (cluster) of the managed Redis instance, but we'll have to prove it first. To help us do this we want to alter our code to work EITHER on a single instance or a cluster.
We have a factory method which currently returns 'Jedis' instances, we'd like it to be able to return an abstraction which can simply implement get, set etc. But it needs to be auto closeable etc (which JedisCommands is not).
I think this needs doing.

[MiltonLai]

I am just checking if this feature had been implemented so that I don't have to do duplicate work.
I have written a little hack in my project to unify JedisCluster and JedisPoolAbstract to avoid client side code changes between different environments.
I really hope this feature will be integrated in official Jedis.

[cbartram]

I second this approach. My program takes options to use an in memory cache or a redis cache and then takes more options to determine if the redis cache should be standalone or clustered. I have a factory that produces the right type of redis cache (standalone vs cluster) however, the logic is duplicated between both redis class types. I.e

class RedisStandalone implements Cache {
     private Jedis cache;

     @Override
     public void hgetAll() { this.cache.hgetAll() ... same as RedisCluster }
     ...
}

class RedisCluster implements Cache {
     private JedisCluster cache;

     @Override
     public void hgetAll() {  this.cache.hgetAll() ... same as RedisStandalone }
     ...
}

What I would really like is an interface which will support standalone or cluster configurations.

class RedisCacheFactory {

    public RedisCache createCache(boolean standalone) {
        return standalone ? new RedisCache<Jedis>() : new RedisCache<JedisCluster>();
    }
}

and for the actual impl just have a single class

class RedisCache<T extends InterfaceForBothStandaloneAndCluster> implements Cache {
   private T cache;
    public void hgetAll() {  cache.hgetAll() ... }
}