Edits to text in Bulk API doc (#39083)
This commit is contained in:
parent
a070cd6822
commit
988ce844e1
|
@ -36,11 +36,11 @@ optional_source\n
|
|||
--------------------------------------------------
|
||||
// NOTCONSOLE
|
||||
|
||||
*NOTE*: the final line of data must end with a newline character `\n`. Each newline character
|
||||
*NOTE*: The final line of data must end with a newline character `\n`. Each newline character
|
||||
may be preceded by a carriage return `\r`. When sending requests to this endpoint the
|
||||
`Content-Type` header should be set to `application/x-ndjson`.
|
||||
|
||||
The possible actions are `index`, `create`, `delete` and `update`.
|
||||
The possible actions are `index`, `create`, `delete`, and `update`.
|
||||
`index` and `create` expect a source on the next
|
||||
line, and have the same semantics as the `op_type` parameter to the
|
||||
standard index API (i.e. create will fail if a document with the same
|
||||
|
@ -214,7 +214,7 @@ documents. See <<optimistic-concurrency-control>> for more details.
|
|||
Each bulk item can include the version value using the
|
||||
`version` field. It automatically follows the behavior of the
|
||||
index / delete operation based on the `_version` mapping. It also
|
||||
support the `version_type` (see <<index-versioning, versioning>>)
|
||||
support the `version_type` (see <<index-versioning, versioning>>).
|
||||
|
||||
[float]
|
||||
[[bulk-routing]]
|
||||
|
@ -245,20 +245,20 @@ NOTE: Only the shards that receive the bulk request will be affected by
|
|||
`refresh`. Imagine a `_bulk?refresh=wait_for` request with three
|
||||
documents in it that happen to be routed to different shards in an index
|
||||
with five shards. The request will only wait for those three shards to
|
||||
refresh. The other two shards of that make up the index do not
|
||||
refresh. The other two shards that make up the index do not
|
||||
participate in the `_bulk` request at all.
|
||||
|
||||
[float]
|
||||
[[bulk-update]]
|
||||
=== Update
|
||||
|
||||
When using `update` action `retry_on_conflict` can be used as field in
|
||||
When using the `update` action, `retry_on_conflict` can be used as a field in
|
||||
the action itself (not in the extra payload line), to specify how many
|
||||
times an update should be retried in the case of a version conflict.
|
||||
|
||||
The `update` action payload, supports the following options: `doc`
|
||||
The `update` action payload supports the following options: `doc`
|
||||
(partial document), `upsert`, `doc_as_upsert`, `script`, `params` (for
|
||||
script), `lang` (for script) and `_source`. See update documentation for details on
|
||||
script), `lang` (for script), and `_source`. See update documentation for details on
|
||||
the options. Example with update actions:
|
||||
|
||||
[source,js]
|
||||
|
@ -282,4 +282,4 @@ POST _bulk
|
|||
[[bulk-security]]
|
||||
=== Security
|
||||
|
||||
See <<url-access-control>>
|
||||
See <<url-access-control>>.
|
||||
|
|
Loading…
Reference in New Issue