couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: More View Changes Input
Date Mon, 06 Oct 2014 19:47:56 GMT
Are you talking about this?

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?


On Fri, Oct 3, 2014 at 2:11 PM, Benoit Chesneau <> wrote:

> On Fri, Oct 3, 2014 at 10:57 PM, <
>> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message