_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"
      ]
  }
}

例如，给定上面的清除树并发出上面的清除请求，整个文档将被清除，因为它只包含一个分支，该分支具有一个叶子修订版 3-c50a32451890a3f1c3e423334cc92745，该修订版将被清除。作为此清除操作的结果，具有 _id:c6114c65e295552ab1019e2b046b10e 的文档将从数据库的文档 b+树和序列 b+树中完全删除。它将无法通过 _all_docs 或 _changes 端点访问，就好像此文档从未存在一样。同样，作为清除操作的结果，数据库的 purge_seq 和 update_seq 将增加。

请注意，修订版 3-b06fcd1c1c9e0ec7c480ee8aa467bf3b 被忽略了。在清除请求中，已清除的修订版和非叶子修订版将被忽略。

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

上面的清除请求将只清除一个分支，使文档的修订版树只有一个分支

作为此清除操作的结果，文档的新更新版本将在 _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 – 文档 ID 到要查找的修订版本列表的映射

响应头：

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，返回不对应于数据库中存储的修订版本的子集。

它的主要用途是复制器，作为一项重要的优化：在从源数据库接收一组新的修订版本 ID 后，复制器将此集合发送到目标数据库的 _revs_diff 以找出其中哪些已经存在。然后，它可以避免获取和发送已知的文档主体。

请求和响应主体都是 JSON 对象，其键是文档 ID；但值结构不同

在请求中，值是该文档的修订版本 ID 数组。
在响应中，值是一个带有 missing 的对象：键，其值为该文档的修订版本 ID 列表（数据库中未存储的那些）以及可选的 possible_ancestors 键，其值为已知可能为丢失修订版本祖先的修订版本 ID 数组。

参数：

db – 数据库名称

请求头：

Accept –
- application/json
- text/plain
Content-Type – application/json

请求 JSON 对象：

object – 文档 ID 到要查找的修订版本列表的映射

响应头：

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`¶