You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Cliffano Subagio <cl...@gmail.com> on 2012/11/20 09:27:41 UTC
deleted database while longpolling _changes
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.
Re: deleted database while longpolling _changes
Posted by Cliffano Subagio <cl...@gmail.com>.
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 <rn...@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 <cl...@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 <rn...@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 <cl...@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.
> > > >
> > >
> >
>
Re: deleted database while longpolling _changes
Posted by Robert Newson <rn...@apache.org>.
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 <cl...@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 <rn...@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 <cl...@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.
> > >
> >
>
Re: deleted database while longpolling _changes
Posted by Cliffano Subagio <cl...@gmail.com>.
"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 <rn...@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 <cl...@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.
> >
>
Re: deleted database while longpolling _changes
Posted by Robert Newson <rn...@apache.org>.
"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 <cl...@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.
>