Are you talking about this? https://github.com/rcouch/rcouch/wiki/Replication-with-view-changes
That's in there. There are two "view changes" things. There's the optimization to db/_changes?filter=_view&view=d/v (for getting a _changes feed filtered by a view in an efficient way) and there's db/_design/d/_view_changes/v (for getting a feed of the changes to key/value pairs in a view) and I'm talking about the latter here. For filtering on the _view_changes feed, there's nothing preventing that from happening in the future, but that's not currently in the PR (as it has slightly different meanings if you're filtering on KVs rather than a doc). For filtering on the seq-indexed db/_changes?filter=_view&view=d/v feed, that has been left relatively unchanged from what you wrote. The question I'm asking in this email is with regard to the second endpoint for the feed of updated key/value pairs and what that API looks like. Does that make sense? Ben On Fri, Oct 3, 2014 at 2:11 PM, Benoit Chesneau <[email protected]> wrote: > On Fri, Oct 3, 2014 at 10:57 PM, [email protected] < > [email protected]> wrote: > > > Yeah, what Paul said is correct. > > > > As far as replication, you would be able to manually mediate a view > > replication with the view changes feed, but there's no built-in > > functionality to do it for you. Unless you're talking about the > > view-filtered replication, which will be optimized if the view is > sequence > > indexed. > > > > > It is in rcouch. So it was about to reuse the code ... > > I do think that such change requires a ticket for those who want to track > at least, but this quite out of topic so just let's talk about this > specific change. > > How does key filtering work with such things? Or isn't it part of the view > change any more? If it is what would be the result? > > On an operational part such changes imply that views changes are about > getting index operations on a doc. Which is conceptually different that > than getting changes on an index. Maybe we could have both, but I think > having index changes is also interesting independently of having index > operations on a doc. It is also covering 2 different usages. Imo having doc > index operations could be done on another resource point. Thoughts? > > - benoit. >
