You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Proof-of-concept for automatic key prefixing
* Iteration on key-prefixing POC
- Demonstrated automatic key-prefixing for all subclasses of
UnifiedJedis: JedisCluster, JedisPooled, and JedisSentineled
- Key-prefixing is possible as long as the underlying CommandObjects can
be customized.
- CommandObjects cannot use commandArguments in its constructor since
in the specific case of key-prefixing, commandArguments depends on the
child constructor running first. So we lose caching of argument-less
CommandObjects.
- Based on this POC, the minimum changes required to jedis would be:
- public constructors that allow UnifiedJedis and its subclasses to
take a custom CommandObjects.
- Consistent use of supplied CommandObjects throughout code (e.g. in
Pipeline, Transaction, etc).
- Removal of caching of argument-less CommandObjects in the
constructor of CommandObjects.
- Applications can then supply CommandObjects with custom behavior as
necessary. Sample classes that implement the behavior of prefixed keys,
etc are provided but these can be supplied by the application as long
as required constructors are available.
* Second iteration on key-prefixing POC
- Restore cached key-less commands in CommandObjects
- Support Transactions
- New constructors do not take CommandExecutor
- Requested JavaDoc regarding new constructors specifying RedisProtocol
- New classes moved into 'prefix' packages
- De-duplicate prefixing code
* Support automatic key prefixing by handler interface
---------
Co-authored-by: R-J Lim <[email protected]>
0 commit comments