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
If I want to query for entries that start with foo in the second separation, it's easy to do. But if I want to check in the bar in the third separation, it's not possible. The only way is to write a more general query, which is more expensive, and then filter it client side.
It would be ideal, if a slightly more advanced "querying/watching" system existed, so we would be able to have more precise key watches (and avoid erroneous events) as well as more efficient queries that don't need to send as much data across the wire to the client.
Some ideas include:
WithRegexp("") that works alongside the WithPrefix option.
WithContains("some string") that matches keys containing a certain pattern.
And so on...
Obviously we need to make sure we pick simple enough matching systems because we don't want to slow down the server side computation, but these basics should be easy first goals.
I'd appreciate other ideas people have for other matching options, as well as ideas on this general proposal.
One more design note: I noticed nobody really ever implemented a proper "ORM" on top of etcd. I considered doing it, but I realized the lack of this kind of feature makes it impossible and/or inefficient. So I think this could unlock quite a lot of use-cases for etcd.
What would you like to be added?
Querying and watching anything but simple key prefixes is not possible. This proposes to add new WithFoo(...) style options so that this is possible.
The most basic Watch or Get filtering operation is done with WithPrefix: https://godocs.io/go.etcd.io/etcd/client/v3#WithPrefix
This is useful because clients can namespace their data (KV data) as follows:
/something/foo1/bar1/somethingelse = data1
/something/foo2/bar2/somethingelse = data2
/something/foo3/bar3/somethingelse = data3
If I want to query for entries that start with
foo
in the second separation, it's easy to do. But if I want to check in thebar
in the third separation, it's not possible. The only way is to write a more general query, which is more expensive, and then filter it client side.It would be ideal, if a slightly more advanced "querying/watching" system existed, so we would be able to have more precise key watches (and avoid erroneous events) as well as more efficient queries that don't need to send as much data across the wire to the client.
Some ideas include:
Obviously we need to make sure we pick simple enough matching systems because we don't want to slow down the server side computation, but these basics should be easy first goals.
I'd appreciate other ideas people have for other matching options, as well as ideas on this general proposal.
One more design note: I noticed nobody really ever implemented a proper "ORM" on top of etcd. I considered doing it, but I realized the lack of this kind of feature makes it impossible and/or inefficient. So I think this could unlock quite a lot of use-cases for etcd.
In my personal situation, this would make queries that my https://github.com/purpleidea/mgmt/ project performs, much more efficient.
Lastly, if someone is interested in writing this patch, I'd be happy to mentor it in my free time if I can.
Thanks!
Why is this needed?
Such a simple feature would make etcd vastly more capable and powerful.
The text was updated successfully, but these errors were encountered: