Why _changes feed seq has format "integer::integer" sometimes?

I am trying to figure out the exact content of continuous _changes feed and am confused with the result rows with seq like “1999::2999”. Would someone know to explain why at times we have this :: notation instead of just single integer, like “1999”?

My understanding this far is that in the example above “1999::2999” means “late arriving sequence” which is sort of pre-notified here, but will appear on the _changes feed later also as seq “2999”?

It’s an obscure implementation detail; nothing a client should need to care about. As a client, just treat sequence IDs as opaque JSON objects and don’t interpret their contents. (For example, Cloudant and BigCouch sequence IDs are long strings of base64.)

Hi! Thanks for reply!

I am trying to keep up with the changes feed in custom listener and it is now unclear how to store the latest seen seq.

Normally I store the seq from each changefeed item as latest seq and use it in _changes POST since-parameter.

–> This part was not correct… it was due to mistake in our code. SG seems to work as expected.
But, when the seq takes format “integer1::integer2”, the _changes since-parameter does not work correctly anymore. I am expecting it to give me changes starting after “integer1::integer2”, but what it does actually, it starts after “integer1”. So practically it rewinds back a lot…

My workaround now is to store the latest seq value by taking the split("::")[1] of the :: -notation. That seems to work correctly.

Please don’t parse or modify the sequence IDs! As I said, you must treat them as opaque. The format or the interpretation could change at any time, which could break your code.

In some edge cases we might end up re-sending existing changes. I’m not involved in Sync Gateway development anymore, but I know there are some very tricky scenarios when users gain/lose access to channels or docs. It may not be feasible for SG to handle them all perfectly and avoid duplication. (@adamf, @andy, any comments on this?)

Ok, good to know, I will recheck how I am utilizing those seq-ids! I also found some detailed info here:

… and also here some hints what the two :: separated values might be:

Investigating more on this: If our changefeed listener has last seq “11112::12345” for example, and then the SG is restarted, the since=“11112::12345” does not work anymore. I have to test more, but I assume that since=“12345” would give the right starting point work after the SG restart.

If we don’t restart SG in the middle of operation, everything seems to work fine now.

Ended up modifying our code so that it does not assume anything about seq format. Now the whole program works fine! : )

But the v. Mobile 1.3 REST documentation of _changes explicitly states that they are integers.

@MLModel Thanks for pointing that out - the docs need to be corrected.

But the v. Mobile 1.3 REST documentation of _changes2 explicitly states that they are integers.

Those docs are for Couchbase Lite, which uses integers as sequence IDs. Sync Gateway does not.