couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "benjamin.bastian@gmail.com" <benjamin.bast...@gmail.com>
Subject Re: View changes API
Date Tue, 19 Aug 2014 03:28:24 GMT
Well, it makes sense to me to have this be as similar to the normal
_changes feed as possible (though maybe the "changes" attribute doesn't
quite make sense in this context). It seems to me that it'd be both useful
and increase the consistency between the two APIs if we included the
revision of the document which triggered the key update. For performance
reasons, I think that'd mean including the rev in the value of the
by-sequence tree. Also, that'd mean if you were doing non-default style or
a filter on a view changes feed, it might affect performance due to
triggering document reads to look up revs, but that's how the normal
changes feed works, so I don't think that's a big deal.

As far as signaling to the user if a key was updated or removed, I'm a bit
more partial to the idea of storing the operation in the value of the seq
tree. That we we could avoid doing a btree lookup in the log tree for every
row in the seq tree fold at query time.

Thoughts?


On Fri, Aug 15, 2014 at 3:34 PM, Benoit Chesneau <bchesneau@gmail.com>
wrote:

> On Thu, Aug 14, 2014 at 1:20 PM, benjamin.bastian@gmail.com <
> benjamin.bastian@gmail.com> wrote:
>
> > For filtered replication, I think it'd be good to keep the rcouch
> > filter=_view optimization when the appropriate flag is enabled. If the
> > flags aren't enabled, fall back on the old, inefficient style of
> filtering.
> >
>
> +1
>
>
> >
> > For someone querying view changes feed, I imagine they'd be interested in
> > which keys and values are changing rather than just which docs in the
> view
> > are changing. So, for a new "view changes" endpoint, I think it'd be good
> > to include the key (as well as the doc ID) in the response body. So, rows
> > would in a response would look something like:
> >
> > {"seq": <seq>, "id", <doc id>, "key": <emitted key>, "changes":
> <changes>}
> >
>
> wwhat would contains the changes ?  I woudl eventually replace by an "op"
> member, saying updated or removed. (Eventually created but that might be
> hard). Something that is actually handled in the latest changes in the view
> log index:
>
>
> https://github.com/rcouch/couchdb-couch-mrview/blob/maint/src/couch_mrview_updater.erl#L359-L366
>
>
>
> > Also, it might be good to add an include_values option to do
> > include_docs-style lookups for the emitted values which correspond to the
> > emitted keys.
> >
>
> +1
>
>
> I still have to look at your code to see how i can help more.
>
> - benoit
>

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