Support wildcard for KV get
AbstractiveNord opened this issue · 11 comments
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.
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
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.
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.
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
- unit1.order_id
- unit2.order_id
- unit3.order_id
- unit4.order_id
- unit5.order_id
Instead of nats kv get orders_status "*.order_id"
And what would the display be? A table of key and value thats all?
And what would the display be? A table of key and value thats all?
Yes, or just simply loop over the keys, similar to nats stream view command output, because metadata, such as timestamp of the key, may be important.
Well its not that simple, because stream view is paged etc and thats quite a lot.
when you could do nats stream view KV_FOO --subject '$KV.KV_FOO.*.order_id :) Doesnt roll off the figures but I am definitely not building stream view on the CLI for KV.
Well its not that simple, because stream view is paged etc and thats quite a lot.
when you could do
nats stream view KV_FOO --subject '$KV.KV_FOO.*.order_id:) Doesnt roll off the figures but I am definitely not building stream view on the CLI for KV.
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.
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.