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
When building an append-only data structure it's important that a strictly increasing identifier is used so all client can agree on the canonical order of entries being added to the log. The seemingly obvious way of building this is using ULIDs, which are strongly hinted at in the Deno KV documentation. This falls apart however when under the effect of multiple writers, such as multiple instances of a Deploy deployment running in separate data centers at the same time1. This could happen because the system clock on all machines don't necessarily match a 100%. This could result in newer entries (as seen from the perspective of the database) being entered before older entries.
To solve this problem (partly) Deno has the commitVersionstamp()function. This is a monotonically increasing counter.
One missing feature compared to FoundationDB is the user_version argument. From the FoundationDB docs:
The user_version should be specified as an integer, but it must fit within a two-byte unsigned integer. It is set by the client, and it is used to impose an order between items serialized within a single transaction. If left unset, then final two bytes of the serialized Versionstamp are filled in with a default (constant) value.
The key sentence being "it is used to impose an order between items serialized within a single transaction". Right now there is no way of writing multiple entries to the log in a single transaction. (One could write multiple entries to the same key of course, but I think the point stands regardless)
It would be great if a user version could be supported in commitVersionstamp.
Footnotes
To be fair, I'm not sure if this is actually an issue on Deploy, but this could definitely happen with other implementations of the kv-connect protocol. ↩
The text was updated successfully, but these errors were encountered:
When building an append-only data structure it's important that a strictly increasing identifier is used so all client can agree on the canonical order of entries being added to the log. The seemingly obvious way of building this is using ULIDs, which are strongly hinted at in the Deno KV documentation. This falls apart however when under the effect of multiple writers, such as multiple instances of a Deploy deployment running in separate data centers at the same time1. This could happen because the system clock on all machines don't necessarily match a 100%. This could result in newer entries (as seen from the perspective of the database) being entered before older entries.
To solve this problem (partly) Deno has the
commitVersionstamp()
function. This is a monotonically increasing counter.One missing feature compared to FoundationDB is the
user_version
argument. From the FoundationDB docs:The key sentence being "it is used to impose an order between items serialized within a single transaction". Right now there is no way of writing multiple entries to the log in a single transaction. (One could write multiple entries to the same key of course, but I think the point stands regardless)
It would be great if a user version could be supported in commitVersionstamp.
Footnotes
To be fair, I'm not sure if this is actually an issue on Deploy, but this could definitely happen with other implementations of the kv-connect protocol. ↩
The text was updated successfully, but these errors were encountered: