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

user344 · March 14, 2016, 6:41pm

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”?

jens · March 16, 2016, 3:15pm

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.)

user344 · March 16, 2016, 3:51pm

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.

EDIT
–> 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.
<–

jens · March 16, 2016, 5:35pm

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?)

user344 · March 16, 2016, 8:41pm

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:

github.com

couchbase/sync_gateway/blob/91e3e8d3cde0010e5f187b1937a9c22fccfa0896/rest/api_test.go#L911-L918


	optStr := `{"feed":"longpoll", "since": "123456:78", "limit":123, "style": "all_docs",
				"include_docs": true, "filter": "Melitta", "channels": "ABC,BBC"}`
	feed, options, filter, channelsArray, _, _, err := h.readChangesOptionsFromJSON([]byte(optStr))
	assert.Equals(t, err, nil)
	assert.Equals(t, feed, "longpoll")


	assert.Equals(t, options.Since.Seq, uint64(78))
	assert.Equals(t, options.Since.TriggeredBy, uint64(123456))

user344 · March 16, 2016, 10:00pm

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.

user344 · March 16, 2016, 10:41pm

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

MLModel · November 5, 2016, 10:51pm

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

adamf · November 5, 2016, 11:46pm

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

jens · November 11, 2016, 12:01am

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.