You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Daniel Gonzalez <go...@gonvaled.com> on 2012/06/20 18:30:16 UTC
Requesting only new changes
Hello,
I am subscribing to the _changes API. My database is quite big, and each
time I restart my client, I get all old notifications. I only need the new
notifications, since the moment that I subscribe to the feed.
I have seen that there is a "since" parameter, but this is not helping me
further, because I do not know what is the last document sequence number.
So I would need one of the following:
- a method to get the last sequence number to use as value for "since"
- a flag to tell the _changes API to just give me the changed *from now
on*. This would be the most clean solution, since it saves me a request to
get the since parameter (which can be outdated anyway very fast). Is there
something like this?
Thanks and regards,
Daniel
Re: Requesting only new changes
Posted by Daniel Gonzalez <go...@gonvaled.com>.
Added:
https://issues.apache.org/jira/browse/COUCHDB-1501
On Thu, Jun 21, 2012 at 12:18 PM, Benoit Chesneau <bc...@gmail.com>wrote:
> On Thu, Jun 21, 2012 at 7:56 AM, Daniel Gonzalez <go...@gonvaled.com>
> wrote:
> > Thanks,
> >
> > I ended up going the GET /dbname route
> > I guess there is no specific flag for the _changes API to request future
> > changes...
> >
> > BR,
> > Daniel
> >
>
> Can you open a ticket describing this feature? It can be interesting
> and trivial to implement.
>
> - benoît
>
Re: Requesting only new changes
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jun 21, 2012 at 7:56 AM, Daniel Gonzalez <go...@gonvaled.com> wrote:
> Thanks,
>
> I ended up going the GET /dbname route
> I guess there is no specific flag for the _changes API to request future
> changes...
>
> BR,
> Daniel
>
Can you open a ticket describing this feature? It can be interesting
and trivial to implement.
- benoît
Re: Requesting only new changes
Posted by Daniel Gonzalez <go...@gonvaled.com>.
Thanks,
I ended up going the GET /dbname route
I guess there is no specific flag for the _changes API to request future
changes...
BR,
Daniel
On Thu, Jun 21, 2012 at 12:03 AM, Johannes J. Schmidt
<sc...@netzmerk.com>wrote:
> Just to mention there is also a update_seq query option, which instructs
> CouchDB to include a update_seq value in the view response, indicating
> which sequence id of the database the view reflects. [1]
> This comes in handy in a situation where you are interested in future
> changes of a view.
>
> g jo
>
> [1] http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
>
> On 06/20/2012 06:42 PM, Robert Newson wrote:
> > Do GET /dbname and the return JSON blob should have the current sequence
> under the update_seq key.
> >
> > B.
> >
> > On 20 Jun 2012, at 17:30, Daniel Gonzalez wrote:
> >
> >> Hello,
> >>
> >> I am subscribing to the _changes API. My database is quite big, and each
> >> time I restart my client, I get all old notifications. I only need the
> new
> >> notifications, since the moment that I subscribe to the feed.
> >>
> >> I have seen that there is a "since" parameter, but this is not helping
> me
> >> further, because I do not know what is the last document sequence
> number.
> >> So I would need one of the following:
> >>
> >> - a method to get the last sequence number to use as value for "since"
> >> - a flag to tell the _changes API to just give me the changed *from now
> >> on*. This would be the most clean solution, since it saves me a request
> to
> >> get the since parameter (which can be outdated anyway very fast). Is
> there
> >> something like this?
> >>
> >> Thanks and regards,
> >> Daniel
>
>
>
Re: Requesting only new changes
Posted by "Johannes J. Schmidt" <sc...@netzmerk.com>.
Just to mention there is also a update_seq query option, which instructs
CouchDB to include a update_seq value in the view response, indicating
which sequence id of the database the view reflects. [1]
This comes in handy in a situation where you are interested in future
changes of a view.
g jo
[1] http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
On 06/20/2012 06:42 PM, Robert Newson wrote:
> Do GET /dbname and the return JSON blob should have the current sequence under the update_seq key.
>
> B.
>
> On 20 Jun 2012, at 17:30, Daniel Gonzalez wrote:
>
>> Hello,
>>
>> I am subscribing to the _changes API. My database is quite big, and each
>> time I restart my client, I get all old notifications. I only need the new
>> notifications, since the moment that I subscribe to the feed.
>>
>> I have seen that there is a "since" parameter, but this is not helping me
>> further, because I do not know what is the last document sequence number.
>> So I would need one of the following:
>>
>> - a method to get the last sequence number to use as value for "since"
>> - a flag to tell the _changes API to just give me the changed *from now
>> on*. This would be the most clean solution, since it saves me a request to
>> get the since parameter (which can be outdated anyway very fast). Is there
>> something like this?
>>
>> Thanks and regards,
>> Daniel
Re: Requesting only new changes
Posted by Robert Newson <rn...@apache.org>.
Do GET /dbname and the return JSON blob should have the current sequence under the update_seq key.
B.
On 20 Jun 2012, at 17:30, Daniel Gonzalez wrote:
> Hello,
>
> I am subscribing to the _changes API. My database is quite big, and each
> time I restart my client, I get all old notifications. I only need the new
> notifications, since the moment that I subscribe to the feed.
>
> I have seen that there is a "since" parameter, but this is not helping me
> further, because I do not know what is the last document sequence number.
> So I would need one of the following:
>
> - a method to get the last sequence number to use as value for "since"
> - a flag to tell the _changes API to just give me the changed *from now
> on*. This would be the most clean solution, since it saves me a request to
> get the since parameter (which can be outdated anyway very fast). Is there
> something like this?
>
> Thanks and regards,
> Daniel