couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliffano Subagio <cliff...@gmail.com>
Subject Re: deleted database while longpolling _changes
Date Wed, 21 Nov 2012 04:31:17 GMT
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 <rnewson@apache.org> 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 <cliffano@gmail.com> 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 <rnewson@apache.org>
> 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 <cliffano@gmail.com>
> 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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message