On Mon, Oct 6, 2014 at 9:47 PM, benjamin.bast...@gmail.com < benjamin.bast...@gmail.com> wrote:
> 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? > What i could say. Getting changes for a group / doc makes sense I guess though it is not what the rcouch merge branch was about and not the reason i given the code for. - benoit > > Ben > > On Fri, Oct 3, 2014 at 2:11 PM, Benoit Chesneau <bchesn...@gmail.com> > wrote: > > > On Fri, Oct 3, 2014 at 10:57 PM, benjamin.bast...@gmail.com < > > benjamin.bast...@gmail.com> 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. > > >
