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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: