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 <[email protected]> wrote: > On Thu, Aug 14, 2014 at 1:20 PM, [email protected] < > [email protected]> 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 >
