[
https://issues.apache.org/jira/browse/COUCHDB-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177312#comment-14177312
]
André Gaul commented on COUCHDB-2396:
-------------------------------------
Hehe, well, ... OK, I got the point. :) So _all_ GET requests are definitely
inappropriate. I guess views are a good starting point for a discussion. For
single/multiple docs it would only be syntactic sugar (which may also help
inexperienced users).
I worked a few months with the meteor framework and I really like the live
updates that you get for _everything_ with a few lines of code. However, I
dislike several other design decisions in the framework (especially when it
comes to nasty global variables and frontend stuff). I spent a few hours
looking for alternatives but receiving live updates from databases doesn't seem
to be very widespread yet (except MongoDB/meteor I found the proprietary
firebase). Since I came to love CouchDB in past projects, I wanted to know if
and how CouchDB's changes functionality can be further improved.
Is the above use case sufficient for assessing the proposed feature? I'd like
to keep it simple... :)
> 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)
