Return-Path: 
 <user-return-22887-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org>
X-Original-To: apmail-couchdb-user-archive@www.apache.org
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id F3B76E163
	for <apmail-couchdb-user-archive@www.apache.org>;
 Tue, 20 Nov 2012 08:45:59 +0000 (UTC)
Received: (qmail 39684 invoked by uid 500); 20 Nov 2012 08:45:58 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 39557 invoked by uid 500); 20 Nov 2012 08:45:57 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@couchdb.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@couchdb.apache.org>
List-Post: <mailto:user@couchdb.apache.org>
List-Id: <user.couchdb.apache.org>
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 39521 invoked by uid 99); 20 Nov 2012 08:45:56 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Nov 2012 08:45:56 +0000
Received: from localhost (HELO mail-vc0-f180.google.com) (127.0.0.1)
  (smtp-auth username rnewson, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Tue, 20 Nov 2012 08:45:56 +0000
Received: by mail-vc0-f180.google.com with SMTP id fk26so1805003vcb.11
        for <user@couchdb.apache.org>; Tue, 20 Nov 2012 00:45:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.180.225 with SMTP id dr1mr19969491vdc.2.1353401155289; Tue,
 20 Nov 2012 00:45:55 -0800 (PST)
Received: by 10.52.69.79 with HTTP; Tue, 20 Nov 2012 00:45:55 -0800 (PST)
In-Reply-To: 
 <CAE+LDp4aAmctGrNOwoOpRyZu1LqHM2nKWgUqZNpYqPPni=vJ0w@mail.gmail.com>
References: 
 <CAE+LDp4aAmctGrNOwoOpRyZu1LqHM2nKWgUqZNpYqPPni=vJ0w@mail.gmail.com>
Date: Tue, 20 Nov 2012 08:45:55 +0000
Message-ID: 
 <CABvT1DGMwBFwpFk7nMdNNhrW9S-XEg7BphJJHwC9kBTEJRRt-Q@mail.gmail.com>
Subject: Re: deleted database while longpolling _changes
From: Robert Newson <rnewson@apache.org>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=bcaec517a99019843a04cee943cf

--bcaec517a99019843a04cee943cf
Content-Type: text/plain; charset=ISO-8859-1

"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.
>

--bcaec517a99019843a04cee943cf--