Thanks for the explanation. The replicator's way of using a _local doc sounds like the best way to go.
On Wed, Nov 21, 2012 at 10:25 AM, Robert Newson <[email protected]> wrote: > 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. > > > > > > > > > >
