-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support wildcard for KV get #1011
Comments
What's the use case for this? There are no multi key behaviours in the cli KV feature at the moment those are best used via clients, but if there's a strong use case I can look |
I use KV as status storage. Every unit has a key, which interpret a some task on unit. Key is formatted as "unit_id.task_id". That feature needs to query task_id across every unit, query all tasks on specific unit_id, etc. |
So what are you doing with the CLI in this scenario? What you describe sounds like something to handle using client libraries, I am specifically asking what you are trying to achieve the with the CLI. My concern is adding too much features like this people end up writing bash scripts using the CLI instead of using our programming libraries. The CLI output format is not a contract and there are no guarantees it wont break such code. So hence asking what the CLI use case is here. |
In case of cli usage, I have to check status on tasks manually, using natscli. It's like a maintenance job. I agree with that concern, but I am not sure that feature will cause people to mess around with bash or something like that. Just a rapid option to check part of the key. |
Let's say that's some ordering system, and user calls support to check order status. Order is bound to some worker, and you as manager wants just check, which units executed logic on that order, is everything ok. Since worker isn't single, it may cause problems to manually check
Instead of |
And what would the display be? A table of key and value thats all? |
Yes, or just simply loop over the keys, similar to |
Well its not that simple, because stream view is paged etc and thats quite a lot. when you could do |
No need to page that. At least not in my request. Yes, I can use view method, or direct calls, but it's a little bit hacky, not for a managers on support. |
For general use and suitabilty to many needs - I would have to page it. |
I got that as not simple, so, well, that's on your discretion. |
Proposed change
Allow use wildcard, star at least, in get queries.
Use case
Keys, separated by dots, can't be effectively used without wildcards. For now, natscli respond with "nats: invalid key".
Contribution
Yes.
The text was updated successfully, but these errors were encountered: