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

Version root level config #7

Closed
tmaiaroto opened this issue Nov 7, 2015 · 2 comments
Closed

Version root level config #7

tmaiaroto opened this issue Nov 7, 2015 · 2 comments

Comments

@tmaiaroto
Copy link
Owner

Unlike etcd, discfg has "versions" for keys. These versions do not reflect global state. They are unique to the keys and simply increment on each modification. This means they are always going to be counting up in order whereas etcd the index value will be skipping around because it refers to a global state across all keys.

However, what we don't have is a root level config. etcd doesn't have a root key value actually...But there's no reason discfg can't. With or without that value, we need a version for the entire config. This root level key will be updated with each child key update.

We will also store a modified date on this key too. Of course this key should have its own independent value version too. So both the global config version and the global config modification time will be special fields that no other key has.

It might also be nice to have this data returned with any key retrieval. Though that would require two queries. So it might best be served as an option.

@tmaiaroto tmaiaroto added this to the Alpha Features milestone Nov 7, 2015
@tmaiaroto
Copy link
Owner Author

DynamoDB is the primary storage engine for discfg. In the future there may be others that are easily used instead...But DynamoDB is not transactional and it has no batch update (there's a batch write - but that doesn't provide the same update options, CAS, etc.).

So this leaves us in a bind. We could "roll back" the last update if the global version/timestamp update fails...But during that period of time, something else could be reading the updated data (which would be inaccurate).

So what I'm going to do is update the version FIRST. Then if that succeeds, modify the key (update/delete is the only thing that changes the global version/modification timestamp).

This still means the modification timestamp isn't 100% accurate (though close) and it is still possible to have the key modification fail so the version is subject to being inaccurate as well. Reverting values is way bad, so the version will just be wrong is all.

It's something I don't see as super critical. It does require two update queries now for each update/delete which is a bummer. But it should be quite fast still. It's just a trade off really. We could do without this global version/modification timestamp, but I find it convenient. Very convenient for applications that want to cache entire configurations and check for updates every now and then. Very convenient for humans who are working with the configuration too.

@tmaiaroto
Copy link
Owner Author

Added, usage: ./discfg info mycfg and ./discfg info mycfg -f json

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