Skip to content
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

Filesystem backend #49

Open
thegrumpylion opened this issue Dec 16, 2017 · 0 comments
Open

Filesystem backend #49

thegrumpylion opened this issue Dec 16, 2017 · 0 comments

Comments

@thegrumpylion
Copy link

Hi,

while ago i've started implementing a local backend driver for libkv using the filesystem. I'm doing this mostly to learn the insides of the codebase (aka for fun) but also some interesting concepts have emerged.

First. What's wrong with boltdb backend?

  • No watching
  • Backed by a binary file

With an FS backend you can utilize inotify to implement watching and you can have plain files as "values". If are accessing your etcd, zk, et. using libkv having a backend like this you can have versioned test/mock data for development and testing. Or, for example, speed development by having direct access to your "DB".

Some issues.

  • Should i treat the key space as flat or as tree. This will affect if i do recursive inotify watch on the dir or not
  • There is some weird normalization stuff for keys that if you follow the functions at the end you just get "/" prepended to your string. So the question is, as a user, should "myKey" be equal to "/myKey" when i call libkv api?
  • File locking. Using fcntl_flock can prevent other process but not the goroutines. sync.Map maybe?

How does this concept sound to you? Will it be useful?

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant