Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <CAEk1YH4yi7vvpXrRKK2oimNh3KO+ze0A+VfVtVK1VWtojwvrWg@mail.gmail.com>
References: <CAEk1YH4yi7vvpXrRKK2oimNh3KO+ze0A+VfVtVK1VWtojwvrWg@mail.gmail.com>
From: Sebastian Rothbucher <sebastianrothbucher@googlemail.com>
Date: Wed, 27 Dec 2017 19:58:18 +0100
Message-ID: <CA+pq5fq9iVkWPRWBX-5McstwGcZMO8HwrzTJoM7CEe=W2vR8+Q@mail.gmail.com>
Subject: Re: strange issue with _changes result ordering
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary="001a113ce1a8908944056156fbdd"
archived-at: Wed, 27 Dec 2017 18:58:36 -0000

--001a113ce1a8908944056156fbdd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
>
> =C2=BB
> Returns a sorted list of changes made to documents in the database, in ti=
me
> order of application, can be obtained from the database=E2=80=99s _change=
s
> resource.
> =C2=AB
>
> 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 o=
ne
> 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=3Dlongpoll&
> heartbeat=3D30000&include_docs=3Dtrue&filter=3Dlog%2Fchannel&
> channel=3Dlugola&since=3D719335-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
>

--001a113ce1a8908944056156fbdd--