+1
-Russell On Fri, Jan 8, 2021 at 11:54 AM 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. > > > > >
