Hi,
There's no easy way to compare them in 2.0 and no requirement for them to be in
order. They are not, in short, designed to be examined or compared outside of
couchdb; treat them opaquely.
The number on the front is the sum of the individual update sequences encoded
in the second part and exists only to trick older versions of the couchdb
replicator into making checkpoints.
The latter half of the sequence string is an encoded list of {node, range, seq}
tuples (where seq is the integer value you know from pre-2.0 releases). When a
sequence string is passed back in, as the since= parameter, couchdb decodes
this string and passes the appropriate integer seq value to the individual
shard.
All that said, in general the front number should increase. The full strings
themselves are not comparable, since there's no defined order to the encoded
list (so two strings could be generated that are encoded differently but decode
to the same list of tuples, just in a different order).
Another aspect to this is that the changes feed is not totally ordered. For a
given shard it _is_ totally ordered (a shard being identical to a pre 2.0
database with an integer sequence), couchdb doesn't shuffle that output (though
correctness of replication would be retained if it did). A clustered database
is comprised of several shards, though (the 'q' value, defaulting to 4 iirc).
The clustered changes feed combines those separate changes feed into a single
one, but makes no effort to impose a total order over that. We don't do it
because it would be expensive and unnecessary.
The contract for /dbname/_changes?since=X is that the response is guaranteed to
include all changes since your X value. The order is not defined, and you might
get changes from before X.
Using binary_to_term(couch_util:decodeBase64Url(EncodedStringHere)).;
Your 99- string decodes to;
[{couchdb@couchdb2,[0,536870911],
{44,<<"2a9602a">>,couchdb@couchdb2}},
{couchdb@couchdb2,[536870912,1073741823],
{0,<<"a093878">>,undefined}},
{couchdb@couchdb2,[1073741824,1610612735],
{4,<<"0979abc">>,couchdb@couchdb2}},
{couchdb@couchdb2,[1610612736,2147483647],
{6,<<"fa6ef9a">>,couchdb@couchdb2}},
{couchdb@couchdb2,[2147483648,2684354559],
{0,<<"b959591">>,undefined}},
{couchdb@couchdb2,[2684354560,3221225471],
{43,<<"cef193e">>,couchdb@couchdb2}},
{couchdb@couchdb2,[3221225472,3758096383],
{0,<<"6d2f0e4">>,undefined}},
{couchdb@couchdb2,[3758096384,4294967295],
{2,<<"497d682">>,couchdb@couchdb2}}]
and your 228- string decodes to;
[{couchdb@couchdb2,[0,536870911],
{105,<<"2a9602a">>,couchdb@couchdb2}},
{couchdb@couchdb2,[536870912,1073741823],
{0,<<"a093878">>,undefined}},
{couchdb@couchdb2,[1073741824,1610612735],
{7,<<"0979abc">>,couchdb@couchdb2}},
{couchdb@couchdb2,[1610612736,2147483647],
{9,<<"fa6ef9a">>,couchdb@couchdb2}},
{couchdb@couchdb2,[2147483648,2684354559],
{3,<<"b959591">>,couchdb@couchdb2}},
{couchdb@couchdb2,[2684354560,3221225471],
{102,<<"cef193e">>,couchdb@couchdb2}},
{couchdb@couchdb2,[3221225472,3758096383],
{0,<<"6d2f0e4">>,undefined}},
{couchdb@couchdb2,[3758096384,4294967295],
{2,<<"497d682">>,couchdb@couchdb2}}].
B.
> On 4 Jun 2017, at 05:04, Geoffrey Cox <[email protected]> wrote:
>
> I’m digging deeper into CouchDB 2 and I’m finding some unexpected ordering
> with sequence numbers. In one case, I found that an early change in a
> _changes feed has the sequence number
>
>
>
> *99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk*
>
>
>
> The last sequence number in my _changes feed, for the same DB, is
>
>
>
> *228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE*
>
>
>
> In a browser console, the following is false
>
>
>
> '228-g1AAAAJFeJyd0EkOgjAUBuAGTJCdN9AjlIKFruQm2jFAEFes9SZ6E72J3gQ7JW7QCGnyXtLhy-vfAgCWVSjAip96XglW-o5afRJQwNbDMDRVSOuj3ogQJRgiOnL_O8I2urKdd4B1KCRpkRcCxH0npKo7KX4ApQH2HogsAElOKOPTBjkY5-yd2DqKYqnItA91C13BRTdNXY0VWouRrV7JDOvmrLuxlLW4VAlJ5Qzr4aznJ2wskIIy-y9sh7wcYoMKLJKRXOACjTxr3uHcsBE'
>>
> '99-g1AAAAI-eJyd0EsOgjAQBuAGiI-dN9C9LmrBwqzkJtrSNkgQV6z1JnoTvYneBEvbhA0aMU1mkj6-_NMSITTJfYFm2anOcsFT10mpTzyG-LxpmiL32eqoN8aEAcWE9dz_jPCFrnzrHGQchiFM4kSgaV0JqQ6VFF-AtAV2DggMgCEGxrNhQfatc3bOyDiKUalg2EBVoCu66KapazcUh41e69-GssjNIvcWWRokk2oNofwj0MNazy4QFURhGQ0J9LKI-SHPIBHEgiak51nxBhxnrRk'
>
>
>
> Is this a bug or do I need to use some other method to compare sequence
> numbers?
>
>
>
> In looking at the other sequence numbers in my _changes feed, it looks like
> they are generally ordered as I would expect, but in this case it appears
> that when the first number, e.g. 99, jumps from 2 digits to 3 digits, the
> ordering breaks. If you boil this down to a simple string comparison
> example, you can see that '228' > '99' => false
>
>
> Thanks.
>
>
> Geoff
