couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Rothbucher <sebastianrothbuc...@googlemail.com>
Subject Re: strange issue with _changes result ordering
Date Wed, 27 Dec 2017 18:58:18 GMT
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...

Hope I help a little as well - all the best. Otherwise feel free to reach
out again
    Sebastian

On Wed, Dec 27, 2017 at 1:46 PM, Damjan Georgievski <gdamjan@gmail.com>
wrote:

> Running a single node CouchDB 2.1.1
>
> Reading: http://docs.couchdb.org/en/2.1.1/api/database/changes.html it
> says
>
> »
> Returns a sorted list of changes made to documents in the database, in time
> order of application, can be obtained from the database’s _changes
> resource.
> «
>
> I have an irc bot that adds a couchdb document with a timestamp for each
> message it sees (and also there are no updates to any documents).
>
> I also have a web page that longpolls the _changes url. things work out
> well enough in a normal situation when the changes feed only returns a
> single document (irc is not that heavy traffic), but if I get more than one
> result in the changes feed they don't come ordered by insertion time
>
> Actually that can be seen with this query too:
>
> curl '
> https://irc.softver.org.mk/api/_changes?feed=longpoll&
> heartbeat=30000&include_docs=true&filter=log%2Fchannel&
> channel=lugola&since=719335-g1AAAAFreJzLYWBg4MhgTmEQTM4vTc
> 5ISXIwNDLXMwBCwxygFFMeC5BkWACk_v__vz8riYExvpmg8gcQ5f9ByhO2EFR-
> AKL8Pkh53Ao8ypMSgGRSPdTk-I34lDqAlMZDlcYWEnREA8QR88FuVsG
> jPJEhSR5qbFwGPhcogFxgD3NsVBYAEpxlew'
> | jq '.results[].doc.timestamp'
>
> Timestamps vary widely:
>
> 1514374352.9027328
> 1514356816.2731326
> 1514373751.1156774
> 1514373763.0645776
> 1514373727.7714481
> 1514375011.2094588
> 1514375223.591063
> 1514370254.6656752
> 1514375022.4995384
> 1514370272.3448327
>
>
> Is this intentional behaviour and the docs are wrong?
>
> --
> damjan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message