3

Say I have a document "schema" that includes a show_from field that contains a timestamp as a Unix epoch. I then create a view keyed by this show_from date and only return those documents with a key on or before the current timestamp (per the request). Thus documents will appear in the view "passively", rather than from any update request.

Is it possible to use the CouchDB change API to monitor this change of view state, or would I have to poll the view to watch for changes? (My guess is the latter, because the change API seems only to be triggered by updates, but just for the sake of confirmation!)

Xophmeister
  • 8,884
  • 4
  • 44
  • 87

1 Answers1

3

The _changes feed can be filtered in a number of ways. One of the ways of filtering the _changes feed is reusing a view's map function.

GET /[DB]/_changes?filter=_view&view=[DESIGN_DOC]/[VIEW_NAME]

Note:

For every _changes request, CouchDB is going to look at each change and run it over the filter function (or in this case the view's map function). None of this is cached for subsequent requests (as on mapreduce views). So it can be quite taxing on resources, unless the changeset is small.

For a large dataset (with many changes) it can be useful to bootstrap with the view, and only incrementally keep track of changes.

Additional info:

Using _changes you can poll for changes since a given sequence point, for the latest N changes, etc. You can also use long polling, or a continuous feed. As long as the changeset to consider (and filter through) is small, it makes sense to use _changes.

But if the view is itself ordered chronologically, as it seems to be your case, it may be pointless to use changes. Just query the view.

Nuno Cruces
  • 1,584
  • 15
  • 18
  • If you have to make a new `_changes` request every time you wanted the view filter to be applied, wouldn't that come to the same thing as polling the view directly? Would, for example, `feed=continuous` update respectively when the view state changed (i.e., without any other update request)? – Xophmeister Jan 12 '16 at 14:31
  • When you poll a view, the view is updated if it is stale, and the update is stored in an index. Subsequent polls just use the index. Polling `_changes` with a filter runs the filter over all changes, every single time. – Nuno Cruces Feb 04 '16 at 15:28
  • `feed=continuous` updates as soon as changes are committed to the database. – Nuno Cruces Feb 04 '16 at 15:32
  • I want to find out which element leaves a view, but there seems to be no eviction event. A second view which `emit()`s all elements which do not make it into the first view does not help, as this second view is updated even on elements, which never make it into the first view. Even worse, when the event on the second view fires, it already is too late to check if the element was in in the first view, as then the first view already is updated, too, and will not contain the element anymore. With only a few million of elements this is easy: Track your own list. But what if there are more? – Tino Jan 25 '21 at 15:06