aboutsummaryrefslogtreecommitdiffstats
path: root/proposals
diff options
context:
space:
mode:
authorBryan Newbold <bnewbold@robocracy.org>2018-07-06 11:30:04 -0400
committerBryan Newbold <bnewbold@robocracy.org>2018-07-06 11:30:06 -0400
commita81c069501ab3c99d8129fde9e4f97958f62fe5f (patch)
treeb70b9f0d50af52ba134fbed7a5bdd04deabad637 /proposals
parent89504750ce92362fa23e5573753eaa5329b490c3 (diff)
downloaddat-deps-a81c069501ab3c99d8129fde9e4f97958f62fe5f.tar.gz
dat-deps-a81c069501ab3c99d8129fde9e4f97958f62fe5f.zip
multiwriter: review feedback
Thanks @mafintosh, @pfrazee
Diffstat (limited to 'proposals')
-rw-r--r--proposals/0000-multiwriter.md22
1 files changed, 13 insertions, 9 deletions
diff --git a/proposals/0000-multiwriter.md b/proposals/0000-multiwriter.md
index e8f931a..8264786 100644
--- a/proposals/0000-multiwriter.md
+++ b/proposals/0000-multiwriter.md
@@ -112,12 +112,15 @@ A "node" is a data structure representing a database entry, including the
`key`, `value`, and feed that the entry is commited to.
`db.get(key)` (as described in the [hyperdb DEP][dep-hyperdb])
-returns an array of nodes. If it is unambiguous what the consistent state of a key is,
-the array will have only that one value. If there is a conflict (ambiguity),
-multiple nodes will be returned. If a key has been deleted from the database, a
-node with the `deleted` flag will be returned; note that such "tombstone" nodes
-can still have a `value` field, which may contain application-specific metadata
-(such as a timestamp).
+returns an array of nodes. If it is unambiguous what the consistent state of a
+key is, the array will have only that one value. If there is a conflict
+(ambiguity), multiple nodes will be returned. If a key has unambiguously been
+removed from the database, a "null" or empty datatype is returned. If one
+branch of a conflict has a deletion (but at least one of the others does not),
+a node with the `deleted` flag will be returned; note that such "tombstone"
+nodes can still have a `value` field, which may contain application-specific
+metadata (such as a self-reported timestamp), which may help resolve the
+conflict.
If multiple nodes are returned from a `get`, the writer should attempt to merge
the values (or chose one over the other) and write the result to the database
@@ -470,9 +473,10 @@ for being more difficult to understand and implement.
What is the actual on-disk layout (folder structure), if not what is documented
here?
-Couldn't the local feed's sequence number be skipped from vector clocks,
-because it's implied by the sequence number of the hypercore entry itself? Same
-with the key in the feed list (for inflated entries).
+The local feed's sequence number could skipped from vector clocks, because it's
+implied by the sequence number of the hypercore entry itself. Same with the key
+in the feed list (for inflated entries). In both cases, the redundant data is
+retained for simplicity.
If there are multiple heads, but they all return the same `value` for a `get()`
operation, how is it decided which `node` will be returned? AKA, values are the