Normalize values across backends about libkv HOT 3 CLOSED

Hi @colebrumley, thanks for reporting the issue and testing out the lib. Much appreciated. There are still inconsistencies, as of now we lag behind the least exhaustive client and API which is etcd. It's usable as long as you don't go past the limits of the least exhaustive client/API (key/value space format).

boltDB is a special case and we would like to split KVs between local and global scopes. boltDB would go along a levelDB/RocksDB driver for example.

Luckily etcd APIv3 will fix all those issues (see the etcd APIv3 rfc). Amongst the changes that would allow for a better abstraction are:

• Binary keys and values
• Removing the directory/key distinction (goes along with the first point)

We can fix it now in libkv (I can fix the directory/key distinction by doing _really_dirty_things_™) but the code is non trivial to achieve something that should be there by default.

from libkv.

Thanks @abronan, that's seems perfectly cromulent to me. In terms of the general approach going forward, is libkv going to stick with the least exhaustive model, or will there eventually be a minimal feature set required of backend drivers?

Feel free to close this issue if you'd like, thanks for the answers!

from libkv.

I think that once we get those subtleties fixed, the classic trio (consul/etcd/zookeeper) is going to be very similar in terms of features without all the convoluted workarounds to make it work. There is a chance to achieve a good abstraction set for those three.

For the rest and if we add more backends, the possibility to vendor stores independently will allow you to choose which set of backends makes the more sense to support based on their features and call supported. I'll make sure I add a compatibility matrix to make this choice more obvious in the future and when I'm going to tag a first release very soon.

Closing this one, feel free to open another issue if you have any more question! Thanks! :)

from libkv.