Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of theboss@purplebulldog.com
 designates 209.85.160.42 as permitted sender)
References: 
 <CAHdxAHv-MTseFVq_f9ieLdh2pxUcthXWJ9MTQ5LwL9Jei4N_RA@mail.gmail.com>
 <CABvT1DECiBbHjFVmug8hmNsh7+wRqVOootc+UTnooTDk42Rh4A@mail.gmail.com>
 <CAHdxAHvEqmRgbR0-qGAM47e=c=ZsJiR+hCRhigE-1CFi7Xtujg@mail.gmail.com>
 <1B06C1C0-F8B9-4ADE-AF66-CB209D602CF5@couchbase.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1B06C1C0-F8B9-4ADE-AF66-CB209D602CF5@couchbase.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCCDBA10-9CC2-4B1E-8B0B-92852AC3E41A@purplebulldog.com>
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>
From: James Hayton <theboss@purplebulldog.com>
Subject: Re: Changes API - purged?
Date: Fri, 23 Aug 2013 09:08:28 -0700
To: "user@couchdb.apache.org" <user@couchdb.apache.org>

So something interesting here to me is that each document had a seq no... Is=
 there any way to figure out what that is from the id/rev? =20

On Aug 23, 2013, at 8:15 AM, Jens Alfke <jens@couchbase.com> wrote:

>=20
> On Aug 23, 2013, at 1:01 AM, Jens Rantil <jens.rantil@gmail.com> wrote:
>=20
>> Just to be clear, does compaction influence the changes feed in any way?
>=20
> It may help to think of the changes feed this way:
>=20
> Every database has a last-sequence counter (similar to a SQL table=E2=80=99=
s autoincrement counter.)
> Every document has a sequence number*.
> Whenever a document is updated (i.e. a revision is added) its sequence num=
ber is changed to the next available sequence count.
> The changes feed is just a listing of documents ordered by their current s=
equence numbers.
> (Under the hood, the database has a separate b-tree index that maps sequen=
ce numbers to document IDs.)
>=20
> Thus the effect is that updating a document moves it to the end of the cha=
nges feed, with a new sequence number.
>=20
> Compaction doesn=E2=80=99t have any effect on this at all; all it does is p=
rune intra-document revision data.
>=20
> =E2=80=94Other Jens ;)
>=20
> * This gets more complex with BigCouch/Cloudant, because it=E2=80=99s clus=
tered. The opaque sequence IDs it shows clients are actually aggregates of t=
he sequence numbers of all the nodes in the cluster.