-1?
I've read over the thread and looked at the foundationdb docs, but I'm
not sure I understand something about the proposal. Given a client
that makes a `_all_docs?include_docs=true` or similar query on a
particular db and that db reaches enough data to always take longer to
work with than the 5 second transaction_too_old timeout, a client must
retry on these 4xx errors to be working as an occasional retry may be
needed, but then will go to fruitless looping retrying and returning
the 400 error as soon as the db grows beyond some unknown point?
If this is the case, then:
Under the proposal under vote, I think a client implementation
following typical v3 examples will appear to work correctly in v4 with
small databases and then fail on databases with real amounts of data
in production with no possible workarounds by couchdb configuration
changes. Expecting people who write clients and test suites to have a
test with realistically large documents might be reasonable, but
expecting people to have a test with "a database that has a large
enough amount of data too take too long" is an opaque requirement.
For the v3 compatible APIs, I therefore think that:
A. Reading of data within a single document never crosses a
transaction boundary.
B. Some (or even all) writes to a db can force a transient error on v3
streaming API reads in progress.
(I.e. for all writes interrupt read streams: each write
transaction increments a field(update_seq?), if that field differs
between the fdb transactions used in a stream read then that read CAN
halt as it MUST return a 400 error.)
I would far prefer that the v3 compatible stream APIs attempt to
emulate stream transactions of indefinite length similar to the
restart_tx Nick V discussed in the original thread. I would prefer
that these interfaces are marked deprecated and can be disabled in
configuration and that a newer clearly distinct API is made following
fdb semantics and removing any unneeded baggage from the v3- APIs.
(I.e. In writing a v4+ client I would like to encounter less
differences in json-output/parameters/etc between _change feeds and
views and I would expect to deal with mandatory pagination handling as
described in the original thread.)
I'm not sure how helpful my input is on the subject, but thank you for
your time,
Will Y
Am Sa., 9. Jan. 2021 um 14:32 Uhr schrieb Robert Newson <rnew...@apache.org>:
>
> The vote is on the proposal text in the quote.
>
> > On 9 Jan 2021, at 04:37, Nick V <vatam...@gmail.com> 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.
> >>>>>
> >>>>>
>
