Skip to content

Commit

Permalink
Clarify _doc is a permanent part of certain document APIs. (#41727)
Browse files Browse the repository at this point in the history
We received some feedback that it is not completely clear why `_doc` is present
in the typeless document APIs:

> The new index APIs are PUT {index}/_doc/{id} in case of explicit ids and POST
{index}/_doc for auto-generated ids."_ Isn't this contradicting? Specifying
*types in requests is deprecated*, but we are supposed to still mention *_doc*
in write requests?

This PR updates the 'removal of types' documentation to try to clarify that
`_doc` now represents the endpoint name, as opposed to a type.
  • Loading branch information
jtibshirani committed May 6, 2019
1 parent 70bf432 commit eb9bce3
Showing 1 changed file with 6 additions and 1 deletion.
7 changes: 6 additions & 1 deletion docs/reference/mapping/removal_of_types.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -270,7 +270,8 @@ Elasticsearch 7.x::
* Specifying types in requests is deprecated. For instance, indexing a
document no longer requires a document `type`. The new index APIs
are `PUT {index}/_doc/{id}` in case of explicit ids and `POST {index}/_doc`
for auto-generated ids.
for auto-generated ids. Note that in 7.0, `_doc` is a permanent part of the
path, and represents the endpoint name rather than the document type.

* The `include_type_name` parameter in the index creation, index template,
and mapping APIs will default to `false`. Setting the parameter at all will
Expand Down Expand Up @@ -554,6 +555,10 @@ GET index/_doc/1
// CONSOLE
// TEST[continued]

NOTE: In 7.0, `_doc` represents the endpoint name instead of the document type.
The `_doc` component is a permanent part of the path for the document `index`,
`get`, and `delete` APIs going forward, and will not be removed in 8.0.

For API paths that contain both a type and endpoint name like `_update`,
in 7.0 the endpoint will immediately follow the index name:

Expand Down

0 comments on commit eb9bce3

Please sign in to comment.