@killergerbah Thank you for your POC.

• This PR considers only cluster mode. Some idea showing non-cluster mode would also be helpful.
• It introduces a new client class JedisClusterWithPrefixedKeys which, IMO, should not be the way to go. One approach could be using config/parameter.
• Manipulating CommandArguments and CommandObjects is an interesting and good idea and can be investigated further.

@sazzad16 Thanks for taking a look.

I have extended the POC to demonstrate an approach that would work for all subclasses of UnifiedJedis. I believe using this approach the only changes required would be to expose constructors that allow customization of CommandObjects. The sample *WithPrefixedKeys classes demonstrate that this is possible.

As mentioned in the commit message, I don't think it's necessary for jedis to provide any of the key-prefixing behavior itself. As long as the constructors are available then applications can customize the behavior of UnifiedJedis as necessary.

It might be worth noting that there is some unavoidable duplicated code in the POC. I believe this is due to CommandArguments being a concrete class and not an interface that can be composed with.

Thanks @sazzad16 for reviewing.

There is one idea that just came to mind that may be worth considering.
Since it seems like you are willing for jedis to support key prefixing as an out-of-the-box behavior, I wonder if it would make sense to make sense to expose this behavior as an additional prefix field in JedisClientConfig. It seems that that would make it easier for callers to use the feature, rather than having to assemble the correct CommandObjects etc.

If that idea does not seem better, then I am happy to continue with this approach.

@sazzad16 I have made the requested changes, and additionally changes to support key-prefixing in transactions. Transaction support required adding CommandObjects.watch, and using CommandObjects for WATCH commands throughout the code.

However, I noticed that there does not seem to be a way to use WATCH with transactions using UnifiedJedis.multi() - is this intentional? Edit: Never mind, I see there is an issue for this (#3662).

Codecov Report

Attention: Patch coverage is 85.93750% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 76.72%. Comparing base (56ef26a) to head (28eb185).
Report is 2 commits behind head on master.

❗ Current head 28eb185 differs from pull request most recent head 66f6336. Consider uploading reports for the commit 66f6336 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@             Coverage Diff              @@
##             master    #3770      +/-   ##
============================================
+ Coverage     76.69%   76.72%   +0.03%     
- Complexity     5130     5150      +20     
============================================
  Files           301      306       +5     
  Lines         15086    15135      +49     
  Branches       1134     1136       +2     
============================================
+ Hits          11570    11613      +43     
- Misses         3015     3019       +4     
- Partials        501      503       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@killergerbah I have tried same feature a bit differently in #3781. Let me know what you think.

@killergerbah I have tried same feature a bit differently in #3781. Let me know what you think.

Thank you. I like your approach because it uses composition instead of inheritance to achieve the same outcome. It also does not require modification of constructors of UnifiedJedis and all of its subclasses. From a caller point of view it is easier to use since it requires just setting the command key processor instead of picking the right constructor to use. I would be supportive of continuing with your branch.