Thanks, then it's a solid +1 from me.
-Joan
On 2021-01-08 4:13 p.m., Robert Newson wrote:
You are probably thinking of a possible “group commit”. That is anticipated and
not contradicted by this proposal. This proposal is explicitly about not using
multiple states of the database for a single doc lookup, view query, etc.
On 8 Jan 2021, at 19:53, Joan Touzet <woh...@apache.org> wrote:
+1.
This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.
-Joan
On 07/01/2021 06:00, Robert Newson wrote:
Hi,
Following on from the discussion at
https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E
<https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29@%3Cdev.couchdb.apache.org%3E>
The proposal is;
"With the exception of the changes endpoint when in feed=continuous mode, that
all data-bearing responses from CouchDB are constructed from a single, immutable
snapshot of the database at the time of the request.”
Paul Davis summarised the discussion in four bullet points, reiterated here for
context;
1. A single CouchDB API call should map to a single FDB transaction
2. We absolutely do not want to return a valid JSON response to any
streaming API that hit a transaction boundary (because data
loss/corruption)
3. We're willing to change the API requirements so that 2 is not an issue.
4. None of this applies to continuous changes since that API call was
never a single snapshot.
Please vote accordingly, we’ll run this as lazy consensus per the bylaws
(https://couchdb.apache.org/bylaws.html#lazy
<https://couchdb.apache.org/bylaws.html#lazy>)
B.
