_purge`¶

POST /{db}/_purge¶

数据库清除将永久删除对数据库中文档的引用。在CouchDB中正常删除文档不会从数据库中删除文档，而是将文档标记为 _deleted=true （并创建新修订）。这是为了确保已删除的文档可以像已删除一样复制到其他数据库中。这也意味着您可以检查文档的状态，并确定该文档已因不存在而被删除。

清除请求必须包含文档ID，对于每个文档ID，必须清除一个或多个修订。可以事先删除文档，但这不是必需的。修订必须是叶修订。

响应将包含成功清除的文档ID和修订的列表。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain Content-Type -- application/json
请求JSON对象:	object -- 将文档ID映射到要清除的修订列表
响应头:	Content-Type -- application/json text/plain; charset=utf-8
响应JSON对象:	purge_seq (string) -- 清除序列字符串 purged (object) -- 将文档ID映射到清除的修订列表
状态代码:	201 Created -- 请求已成功完成 202 Accepted -- 请求已被接受，并在至少一个副本上成功完成，但未达到仲裁。 400 Bad Request -- 数据库名称或JSON负载无效 415 Unsupported Media Type -- 坏的 Content-Type 价值 500 Internal Server Error -- 内部服务器错误或超时

请求：

POST /db/_purge HTTP/1.1
Accept: application/json
Content-Length: 76
Content-Type: application/json
Host: localhost:5984

{
    "c6114c65e295552ab1019e2b046b10e": [
        "3-b06fcd1c1c9e0ec7c480ee8aa467bf3b",
        "3-c50a32451890a3f1c3e423334cc92745"
    ]
}

响应：

HTTP/1.1 201 Created
Cache-Control: must-revalidate
Content-Length: 107
Content-Type: application/json
Date: Fri, 02 Jun 2017 18:55:54 GMT
Server: CouchDB/2.0.0-2ccd4bf (Erlang OTP/18)

{
  "purge_seq": null,
  "purged": {
    "c6114c65e295552ab1019e2b046b10e": [
        "3-c50a32451890a3f1c3e423334cc92745"
      ]
  }
}

文件修订树1

例如，给定上述清除树并发出上述清除请求，整个文档将被清除，因为它只包含具有叶修订的单个分支 3-c50a32451890a3f1c3e423334cc92745 that will be purged. As a result of this purge operation, a document with _ ID：c6114c65e295552ab1019e2b046b10e`将从数据库的文档b+树和序列b+树中完全删除。它将不会通过以下方式提供 ``_all_docs` 或 _changes 端点，就好像这个文档从未存在过一样。同样作为清除操作的结果，数据库的 purge_seq 和 update_seq 将会增加。

注意，怎么修改 3-b06fcd1c1c9e0ec7c480ee8aa467bf3b 被忽略。清除请求中将忽略已清除的修订和非叶修订。

如果一个文档有两个具有以下修订历史记录的冲突修订：

文件修订树2

上述清除请求将只清除一个分支，使文档的修订树只剩下一个分支：

文件修订树3

作为此清除操作的结果，文档的新更新版本将在 _all_docs 和 _changes ，在中创建新记录 _changes 。数据库的 purge_seq 和 update_seq 将会增加。

1.3.18.1. 内部复制¶

清除在同一数据库的副本之间自动复制。每个数据库都有一个内部清除树，其中存储一定数量的最新清除。这允许在同一数据库的副本之间进行内部同步。

1.3.18.2. 外部复制¶

清除操作不会复制到其他外部数据库。外部复制的工作原理是标识目标上缺少的源文档修订，然后将这些修订从源复制到目标。清除操作将从文档的清除树中完全清除修订，从而使清除无法进行外部复制。

注解

如果需要清除跨多个有效数据库有效，则必须在每个数据库上分别运行清除。

1.3.18.3. 正在更新索引¶

使用清除序列跟踪数据库上的清除次数。视图索引器使用它来优化包含已清除文档的视图的更新。

每个内部数据库索引器（包括视图索引器）都保留自己的清除序列。存储在索引中的清除序列可以比数据库的清除序列小得多，直到允许存储在数据库清除树中的清除请求数为止。索引器可以处理多个清除请求，而无需重新生成索引。索引将根据这些清除请求进行更新。

文档索引基于修订树的获胜者。根据清除请求中指定的修订，索引更新会观察以下行为：

如果清除请求中未指定修订树的获胜者，则不会更改此文档的索引记录。
如果清除请求中指定了修订树的优胜者，并且清除后仍有修订，则根据修订树的新获胜者建立文档的索引记录。
如果清除请求中指定了文档的所有修订，则将删除文档的索引记录。将不再在搜索中找到该文档。

1.3.19. `/db/_purged_infos_limit`¶

GET /{db}/_purged_infos_limit¶

获取当前 purged_infos_limit （清除文档限制）设置，可以存储在数据库中的历史清除（清除的文档ID及其修订）的最大数量。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain
响应头:	Content-Type -- application/json text/plain; charset=utf-8
状态代码:	200 OK -- 请求已成功完成

请求：

GET /db/_purged_infos_limit HTTP/1.1
Accept: application/json
Host: localhost:5984

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 5
Content-Type: application/json
Date: Wed, 14 Jun 2017 14:43:42 GMT
Server: CouchDB (Erlang/OTP)

1000

PUT /{db}/_purged_infos_limit¶

设置将在数据库中跟踪的最大清除数（请求的清除ID及其修订版），即使在进行了压缩之后也是如此。您可以使用要设置为请求正文的限制的标量整数来设置数据库的清除文档限制。

历史存储清除的默认值为1000。这意味着，在执行清除时，同一数据库的副本之间最多可以同步1000个清除操作，以防其中一个副本关闭。

此请求设置存储清除的软限制。在压实过程中，CouchDB将尽量保持 _purged_infos_limit 数据库中的清除数，但有时存储的清除数可以超过此值。如果数据库尚未完成与活动索引或活动内部复制的清除同步，则它可能会临时存储更多的历史清除。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain Content-Type -- application/json
响应头:	Content-Type -- application/json text/plain; charset=utf-8
响应JSON对象:	ok (boolean) -- 运行状态
状态代码:	200 OK -- 请求已成功完成 400 Bad Request -- 无效的JSON数据

请求：

PUT /db/_purged_infos_limit HTTP/1.1
Accept: application/json
Content-Length: 4
Content-Type: application/json
Host: localhost:5984

1500

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Wed, 14 Jun 2017 14:45:34 GMT
Server: CouchDB (Erlang/OTP)

{
    "ok": true
}

1.3.20. `/db/_missing_revs`¶

POST /{db}/_missing_revs¶

对于给定的文档修订列表，返回数据库中不存在的文档修订。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain Content-Type -- application/json
请求JSON对象:	object -- 从修订到文档列表的查找
响应头:	Content-Type -- application/json text/plain; charset=utf-8
响应JSON对象:	missing_revs (object) -- 将文件ID映射到缺失修订列表
状态代码:	200 OK -- 请求已成功完成 400 Bad Request -- 数据库名称或JSON负载无效

请求：

POST /db/_missing_revs HTTP/1.1
Accept: application/json
Content-Length: 76
Content-Type: application/json
Host: localhost:5984

{
    "c6114c65e295552ab1019e2b046b10e": [
        "3-b06fcd1c1c9e0ec7c480ee8aa467bf3b",
        "3-0e871ef78849b0c206091f1a7af6ec41"
    ]
}

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 64
Content-Type: application/json
Date: Mon, 12 Aug 2013 10:53:24 GMT
Server: CouchDB (Erlang/OTP)

{
    "missing_revs":{
        "c6114c65e295552ab1019e2b046b10e": [
            "3-b06fcd1c1c9e0ec7c480ee8aa467bf3b"
        ]
    }
}

1.3.21. `/db/_revs_diff`¶

POST /{db}/_revs_diff¶

给定一组文档/修订ID，返回与数据库中存储的修订不对应的子集。

它的主要用途是由replicator作为一个重要的优化：在从源数据库接收到一组新的修订id之后，replicator将这个集合发送到目标数据库的 _revs_diff 找出他们中的哪一个已经存在。这样就可以避免获取和发送已知的文档体。

请求和响应主体都是JSON对象，它们的键是文档id；但是值的结构不同：

在请求中，值是该文档的修订ID数组。
在响应中，值是具有 missing ：key，其值是该文档的修订ID列表（未存储在数据库中的修订ID）和可选的 possible_ancestors 键，其值是已知的修订ID数组，这些修订ID可能是缺失修订的祖先。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain Content-Type -- application/json
请求JSON对象:	object -- 从修订到文档列表的查找
响应头:	Content-Type -- application/json text/plain; charset=utf-8
响应JSON对象:	missing (array) -- 指定文件遗漏修订清单 possible_ancestors (array) -- 修订列表可能是指定文档的祖先及其在请求的数据库中的当前修订
状态代码:	200 OK -- 请求已成功完成 400 Bad Request -- 数据库名称或JSON负载无效

请求：

POST /db/_revs_diff HTTP/1.1
Accept: application/json
Content-Length: 113
Content-Type: application/json
Host: localhost:5984

{
    "190f721ca3411be7aa9477db5f948bbb": [
        "3-bb72a7682290f94a985f7afac8b27137",
        "4-10265e5a26d807a3cfa459cf1a82ef2e",
        "5-067a00dff5e02add41819138abb3284d"
    ]
}

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 88
Content-Type: application/json
Date: Mon, 12 Aug 2013 16:56:02 GMT
Server: CouchDB (Erlang/OTP)

{
    "190f721ca3411be7aa9477db5f948bbb": {
        "missing": [
            "3-bb72a7682290f94a985f7afac8b27137",
            "5-067a00dff5e02add41819138abb3284d"
        ],
        "possible_ancestors": [
            "4-10265e5a26d807a3cfa459cf1a82ef2e"
        ]
    }
}

1.3.22. `/db/_revs_limit`¶

GET /{db}/_revs_limit¶

获取当前 revs_limit （修订限制）设置。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain
响应头:	Content-Type -- application/json text/plain; charset=utf-8
状态代码:	200 OK -- 请求已成功完成

请求：

GET /db/_revs_limit HTTP/1.1
Accept: application/json
Host: localhost:5984

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 5
Content-Type: application/json
Date: Mon, 12 Aug 2013 17:27:30 GMT
Server: CouchDB (Erlang/OTP)

1000

PUT /{db}/_revs_limit¶

设置CouchDB将跟踪的文档修订的最大数量，即使在压缩发生之后也是如此。您可以使用要设置为请求正文的限制的标量整数对数据库设置修订限制。

参数:	db -- 数据库名称
请求标头:	Accept -- application/json text/plain Content-Type -- application/json
响应头:	Content-Type -- application/json text/plain; charset=utf-8
响应JSON对象:	ok (boolean) -- 运行状态
状态代码:	200 OK -- 请求已成功完成 400 Bad Request -- 无效的JSON数据

请求：

PUT /db/_revs_limit HTTP/1.1
Accept: application/json
Content-Length: 5
Content-Type: application/json
Host: localhost:5984

1000

响应：

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Mon, 12 Aug 2013 17:47:52 GMT
Server: CouchDB (Erlang/OTP)

{
    "ok": true
}

1.3.18. /db/_purge¶

1.3.18.1. 内部复制¶

1.3.18.2. 外部复制¶

1.3.18.3. 正在更新索引¶

1.3.19. /db/_purged_infos_limit¶

1.3.20. /db/_missing_revs¶

1.3.21. /db/_revs_diff¶

1.3.22. /db/_revs_limit¶

1.3.18. `/db/_purge`¶

1.3.19. `/db/_purged_infos_limit`¶

1.3.20. `/db/_missing_revs`¶

1.3.21. `/db/_revs_diff`¶

1.3.22. `/db/_revs_limit`¶