|
@@ -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>>.
|