I just wanted to suggest to add the TYPE filter as a feature in redis commander for the initial SCAN (in case USE_SCAN is set) in addition to MATCH (which uses ROOT_PATTERN).
For me this would be really nice, because I am having 100k similar string keys, but I am actually mostly interested in just 5 lists or so. If there was a negative filter (or regex) for MATCH, I could use that, but unfortunately that's not possible. The 100k strings cause a lot of load locally for some reason.
In case adding the TYPE parameter is something you would be interested in, I could also do a PR. Maybe call it ROOT_TYPE?
in "default.json" an empty pattern config entry should be provides to not change default behaviour
ROOT_TYPE seems resonable compared to existing env vars (defined in "custom-environment-variables.json")
using "keys" instead of "scan" the parameter is ignored. Maybe a warning on startup that type is set without using scan might be helpful. But this should not be printed on every scan run.
Hi,
I just wanted to suggest to add the TYPE filter as a feature in redis commander for the initial SCAN (in case USE_SCAN is set) in addition to MATCH (which uses ROOT_PATTERN).
For me this would be really nice, because I am having 100k similar string keys, but I am actually mostly interested in just 5 lists or so. If there was a negative filter (or regex) for MATCH, I could use that, but unfortunately that's not possible. The 100k strings cause a lot of load locally for some reason.
In case adding the TYPE parameter is something you would be interested in, I could also do a PR. Maybe call it ROOT_TYPE?