From the docs at http://docs.couchdb.org/en/2.1.1/api/database/changes.html;
"Warning
The results returned by _changes are partially ordered. In other words, the
order is not guaranteed to be preserved for multiple calls."
This is true even for single node setups.
Some extra text from docs.cloudant.com that we should incorporate into the
couchdb docs;
"In particular, if you ask for a list of changes _since a sequence identifier,
you get the requested information in response. But you might also get changes
that were made before the change indicated by the sequence identifier. The
reason these extra changes are included, along with the implications for
applications, is explained in the replication guide.
Note: Any application that uses the _changes request must be able to process
correctly a list of changes that might:
• Have a different order for the changes that are listed in the
response, when compared with an earlier request for the same information.
• Include changes that are considered to be before the change specified
by the sequence identifier"
B.
> On 27 Dec 2017, at 23:08, Damjan Georgievski <[email protected]> wrote:
>
> On 27 December 2017 at 19:58, Sebastian Rothbucher <
> [email protected]> wrote:
>
>> Hi Damjan,
>>
>> thanks for reaching out - and yes, there is an explanation for this thing -
>> e.g. here https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/
>> and
>> here https://blog.couchdb.org/2016/08/17/migrating-to-couchdb-2-0/ (search
>> for 'changes'). Long story short: as CouchDB is clustered by default, it
>> does its best to consolidate from several shards which might cause the
>> shuffle you experience. Esp. for documents with close timestamps.
>>
>> Ad-hoc, I'm not sure about the docs right now. But as you stumbled: can you
>> open an issue or PR for the doc page in question, that would really help a
>> lot...
>>
>
> What is not clear from those blog posts (and the official documentation
> seems to further the confusion) is if that applies to single-node 2.x
> instances too.
>
> (ps. those were not documents with close timestamps - they were hours
> appart)
>
> I guess the docs are just plain wrong now at this time?
>
>
> --
> damjan
