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 <[email protected]> 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. >> >>
