假设我有一个文档“模式”，其中包含一个 show_from 字段，该字段包含一个时间戳作为 Unix 纪元。然后，我创建一个以show_from 日期为键的视图，并且仅返回那些键在当前时间戳上或之前的文档（根据请求）。因此文档将“被动地”出现在视图中，而不是来自任何更新请求。
是否可以使用 CouchDB 更改 API 来监视视图状态的这种更改，还是我必须轮询视图以观察更改？ （我的猜测是后者，因为更改API似乎只是更新触发，但只是为了确认！）
【问题讨论】：
标签： view couchdb polling watch
_changes 提要可以通过多种方式成为filtered。
过滤_changes 提要的方法之一是重用view's map function。
GET /[DB]/_changes?filter=_view&view=[DESIGN_DOC]/[VIEW_NAME]
注意：
对于每个_changes 请求，CouchDB 将查看每个更改并通过过滤器函数（或者在本例中为视图的地图函数）运行它。这些都不会为后续请求缓存（如在 mapreduce 视图上）。因此，除非变更集很小，否则它可能会占用大量资源。
对于大型数据集（包含许多更改），使用视图引导很有用，并且仅增量跟踪更改。
附加信息：
使用_changes，您可以轮询自给定序列点以来的更改、最新的 N 更改等。您还可以使用长轮询或连续馈送。只要要考虑（和过滤）的变更集很小，就可以使用_changes。
但是，如果视图本身是按时间顺序排列的，就像您的情况一样，使用更改可能毫无意义。只需查询视图。
【讨论】：
_changes 请求，那与直接轮询视图不一样吗？例如，feed=continuous 会在视图状态更改时分别更新（即，没有任何其他更新请求）吗？
_changes 每次都会对所有更改运行过滤器。
feed=continuous 会在更改提交到数据库后立即更新。
emit()s 所有未进入第一个视图的元素的第二个视图无济于事，因为即使在元素上也更新了第二个视图，这些元素从未进入第一个视图。更糟糕的是，当第二个视图上的事件触发时，检查元素是否在第一个视图中已经为时已晚，因为第一个视图也已经更新，并且不再包含该元素。只有几百万个元素，这很容易：跟踪您自己的列表。但如果还有更多呢？