"Can the empty results array be used to identify that the database was deleted?"
No, you'll get the same result on a timeout. "What is the reasoning behind returning since parameter value 123 instead of the real last_seq 0?" That does look wrong at first glance but it's because we start reading the internal by_seq view at the since value, the last_seq value is reported as the final key we iterate over, so by sending a key greater than the end of the database (something the primary consumer of _changes feeds, the replicator, would never do) we find no rows, terminating immediately, but reporting the last_seq value we have. We could probably fix that but it sounds a little fiddly. You can't determine last_seq using the _changes feed, given the above, but the correct value is reported as update_seq in the result of GET /dbname. B. On 20 November 2012 08:27, Cliffano Subagio <[email protected]> wrote: > Hi, > > I have a database which _changes notification is being longpolled. > I notice that when I delete this database, the response body will have > results containing an empty array, along with a last_seq property, and > status code 200. > > Can the empty results array be used to identify that the database was > deleted? > Is there any other events that might result in an empty results array? > > > Another thing I'm curious about is the last_seq property value. > I created a new database, query dbname/_changes, it return last_seq 0 as > expected > > {"results":[ > > ], > "last_seq":0} > > But when I query dbname/_changes?heartbeat=1000&feed=longpoll&since=123 > I get the since parameter value as last_seq property value, like this > > {"results":[ > ...<newlines here> > ], > "last_seq":123} > > What is the reasoning behind returning since parameter value 123 instead of > the real last_seq 0? > Just by checking the response body, how to determine whether last_seq 123 > is really the number of changes in the database? or if 123 is only since > parameter value? > > > Cheers, > Cliff. >
