> I withdraw my vote until I can get a clearer view. Nick would you mind re-stating?
Not at all! The longer version and other considerations was stated in my last reply to the discussion thread so I assumed that was accepted as a consensus since nobody replied arguing otherwise. https://lists.apache.org/thread.html/r45bff6ca4339f775df631f47e77657afbca83ee0ef03c6aa1a1d45cb%40%3Cdev.couchdb.apache.org%3E But the gist of it is that existing (< 3.x) replicators won't be able to replicate non-continuous (normal) changes from >= 4.x endpoints. Regards, -Nick On Sat, Jan 9, 2021 at 1:26 AM Joan Touzet <woh...@apache.org> wrote: > > Wait, what? I thought you agreed with this approach in that thread. > > I withdraw my vote until I can get a clearer view. Nick would you mind > re-stating? > > -Joan > > On 2021-01-08 11:37 p.m., Nick V wrote: > > +1 for 1 through 3 > > > > -1 for 4 as I think the exception should apply to normal change feeds as > > well, as described in the thread > > > > Cheers, > > -Nick > > > >> On Jan 8, 2021, at 17:12, Joan Touzet <woh...@apache.org> wrote: > >> > >> 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. > >>>>> > >>>>>
