We close pending changes feeds when the db is deleted, that's all. If you had updated the db, you'd had seen the update, but the next thing that happened after the _changes call was the delete.
You can check the instance_start_time of the database, it will change if the db is deleted and recreated. That said, the way that the replicator detects this situation is stronger, it creates a _local doc which records the since value it should use next time. A delete/recreate will delete this document, and so the replicator knows to start at 0. On 20 November 2012 23:03, Cliffano Subagio <[email protected]> wrote: > "No, you'll get the same result on a timeout." > > Does that mean that the empty results after the database deletion is also > caused by a timeout? > > "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." > > Let's say the client is longpolling _changes feed with 'since' parameter > 500. > The database is deleted then recreated, > (a) the client gets a response with last_seq 500, while GET /dbname > update_seq is 0 > (b) three documents are then added to the database within a short period of > time (there are other clients writing to the database). > > The client needs to reset 'since' parameter because the database's last > sequence is no longer 500, but when it sends a request GET /dbname > update_seq, the update_seq is already 3, which means the client misses out > 3 changes between (a) and (b). > Another option is to reset 'since' parameter to 0, but this is not good > when the empty results is caused by a legitimate timeout and not a database > deletion, the client needs to rescan the changes from the beginning. > > What would be the correct way to determine the next 'since' parameter value > since last_seq and update_seq can't be used in above situation? > > > On Tue, Nov 20, 2012 at 7:45 PM, Robert Newson <[email protected]> wrote: > > > "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. > > > > > >
