[
https://issues.apache.org/jira/browse/COUCHDB-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177238#comment-14177238
]
André Gaul commented on COUCHDB-2396:
-------------------------------------
OK, assume we've got simple counting map/reduce functions
{code:javascript}
function map (doc) {
if (doc.type === "comment") {
emit(doc.post_id, 1);
}
}
{code}
and
{code:javascript}
function reduce (keys, values, rereduce) {
return sum(values);
}
{code}
Let's run {{curl -X GET
"http://couch/test/_design/ddoc/_view/comment_count?group=true&limit=1&update_seq=true"}}
{code:javascript}
{"update_seq":15,"rows":[
{"key":"blogpost1","value":2}
]}
{code}
I could use the {{_changes}} feed with a view filter in order to get updates
for involved documents. Since I know the involved (map/reduce-)logic, I could
go ahead and try to undo the reduce upon deletion and execute it upon insertion
of documents. All this would need to happen in the client.
It would be awesome, if appending {{?changes=true&since=15}} to the above URL
returns a (perhaps continuous) changeset for the "rows" in the above response.
Since CouchDB knows all information it needs, all logic could be carried out by
CouchDB – thus facilitating the work of CouchDB users. I can imagine that
performance issues may arise with such an approach, though. ;)
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?! :)
> 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)
