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
{{ message }}
This repository has been archived by the owner on Jan 9, 2024. It is now read-only.
So right now there is a mix of server management commands or other command that is usually unrelated to normal redis-server operations like GET/SET/LISTS/HASH/ZSET/GEO and more. Some command and features is more used in the administration side of things for a redis cluster and then you should not really be using them in a normal cluster client usage anyway.
In the past there has been a similar class like this that would facilitate cluster management and other separate commands but that feature was removed as it was merged into the main RedisCluster client class. But since we still have commands remaining inside the client that is blocked that should really be sorted out and a implementation that works for all commands should be sorted out.
One of the main problems with the RedisCluster client is that a lot of the management style commands have to make a decision of what cluster implementation that you want to use to execute the function and make a decision on the data side of things.
This change would facilitate both solutions as it would provide some default execution logics for any management function but it would also expose different methods and features for the client user to easily implement their own cluster logic based on their own needs.
Make a separate Management Class
Implement some of the commands we know and have a solution for to facilitate a default way to execute some commands
Implement iterator methods that will enable looping over different sets of redis nodes in the cluster. iterate_all_nodesiterate_master_nodesiterate_slave_nodesiterate_startup_nodes. These methods would either return a regular Redis` class instance that points to each node in the cluster or it would be passed through RedisCluster to use any new cluster logic if needed.
Block out more functions from RedisCluster class as they are moved/reimplemented in the management class
more to come...
The text was updated successfully, but these errors were encountered:
So right now there is a mix of server management commands or other command that is usually unrelated to normal redis-server operations like GET/SET/LISTS/HASH/ZSET/GEO and more. Some command and features is more used in the administration side of things for a redis cluster and then you should not really be using them in a normal cluster client usage anyway.
In the past there has been a similar class like this that would facilitate cluster management and other separate commands but that feature was removed as it was merged into the main RedisCluster client class. But since we still have commands remaining inside the client that is blocked that should really be sorted out and a implementation that works for all commands should be sorted out.
One of the main problems with the RedisCluster client is that a lot of the management style commands have to make a decision of what cluster implementation that you want to use to execute the function and make a decision on the data side of things.
This change would facilitate both solutions as it would provide some default execution logics for any management function but it would also expose different methods and features for the client user to easily implement their own cluster logic based on their own needs.
iterate_all_nodes
iterate_master_nodes
iterate_slave_nodes
iterate_startup_nodes. These methods would either return a regular
Redis` class instance that points to each node in the cluster or it would be passed through RedisCluster to use any new cluster logic if needed.The text was updated successfully, but these errors were encountered: