Stefan is right. The sequence value that is returned in 2.x includes encoded information about which nodes you are talking to. This info is used when resuming the _changes feed in the future, so you can be sure you don't miss out on any changes.
I covered this during my recent talk at ApacheCon 2018 - with thanks to Robert Newson who posted a message describing this on the list a few years ago. It's slides 52-58: https://speakerdeck.com/wohali/another-10-common-misconceptions-about-apache-couchdb?slide=52 There's a recording, audio only, here: https://feathercast.apache.org/2018/09/29/another-10-common-misconceptions-about-apache-couchdb-joan-touzet/ Subtle, but this is why it's important to retain your _seq number (or last_seq) and provide it on subsequent calls. -Joan ----- Original Message ----- > From: "Stefan Klein" <st.fankl...@gmail.com> > To: user@couchdb.apache.org > Sent: Monday, October 8, 2018 7:31:15 AM > Subject: Re: Strange behavior of the _changes api > > Hi, > > Am Mo., 8. Okt. 2018 um 10:55 Uhr schrieb 蒋鹏程 > <jiang.pengch...@navercorp.com > >: > > > > > Could someone explain this for me? Many thanks. > > > > > The order of the changes feed is not guaranteed to be preserved > between > multiple calls, so the "first" change may be a different one on each > call. > As a heads-up, if you use the "since" parameter it's only guaranteed > you > see all changes that happened after that one, it is NOT guaranteed > you will > not see a change before that one. > > If you think of a cluster setup, it's hard to define the order of > changes. > Document A might be submitted to node A and document B to node B, > you're > talking to node C, which order is correct, AB or BA? > > regards, > Stefan >
