incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: deleted database while longpolling _changes
Date Tue, 20 Nov 2012 08:45:55 GMT
"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