couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shorin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2396) Provide ?changes=true for all GET requests
Date Mon, 20 Oct 2014 18:30:34 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177255#comment-14177255
] 

Alexander Shorin commented on COUCHDB-2396:
-------------------------------------------

{quote}
I'm not focused on changes for single/multiple docs but I'm interested in a general discussion
if appending something like ?changes=true to any GET request is feasible. Maybe I was not
clear enough about this?! 
{quote}

No, you're pretty clean on this(: But any GET is too broad requirement. Should it be applicable
for {{/db}} and {{/db/_security}} resources? You probably want to subscribe to {{/_config}}
changes, but they don't have any seq to count since. How to deal with {{/_stats}} which will
generate events on every request CouchDB gets? Does this proposal includes changes for {{/db/_local}}
documents which are currently out of sight database changes feed? What about show and list
functions? And there is certainly will be fun with {{/_uuids}} (: 

That's why I started wondering about use cases - they could help to find out the right solution
of the real problem.

> Provide ?changes=true for all GET requests
> ------------------------------------------
>
>                 Key: COUCHDB-2396
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2396
>             Project: CouchDB
>          Issue Type: Wish
>      Security Level: public(Regular issues) 
>          Components: HTTP Interface
>            Reporter: André Gaul
>
> h2. Situation
> Assume you've made one of the following HTTP requests against a CouchDB:
> * GET /albums/foobar
> * GET /albums/_design/ddoc/_view/by_name?startkey=foo
> In a lot of applications, you're interested in the changes that happened since the last
request or you even want to receive continuous/live updates (e.g., via [Server Sent Events|http://www.w3.org/TR/eventsource/]).
Actually, that's what CouchDB's _changes feed is made for (and it does a good job in a few
projects I maintain). CouchDB 2.0 seems to go a step further by providing a changes feed for
views (according to a discussion with [~janl] on irc, see also [here|https://github.com/rcouch/rcouch/wiki/View-Changes]).
However, the _changes feed is a bit hard to use if you want to get the changes for a specific
request with all involved parameters (e.g., for the above view query).
> h2. Improvement
> From a user's perspective, it would be much simpler if the changes could be fetched for
a specific request by simply appending _?changes=true_ and a _since_ parameter whose value
was provided by the previous request, e.g. by
> * GET /albums/foobar?changes=true&since=4711
> * GET /albums/_design/ddoc/_view/by_name?startkey=foo&changes=true&since=4711
> Technically, the changes reply could consist of [JSON patches|https://tools.ietf.org/html/rfc6902].
> This kind of _changes_ feature would be great for all REST APIs in the context of (near-)
real time apps. CouchDB probably has almost everything in place to support this feature and
make life much easier ;). On the other hand, I can imagine that it requires a significant
amount of work in CouchDB's internals.
> Since I'm not too familiar with CouchDB's internals, I'd like to bring this idea up for
discussion here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message