Skip to content

Commit d013289

Browse files
committed
Update 'removal of types' docs to reflect the new plan.
Backport of #38003.
1 parent 2a0ecb9 commit d013289

File tree

1 file changed

+109
-17
lines changed

1 file changed

+109
-17
lines changed

docs/reference/mapping/removal_of_types.asciidoc

Lines changed: 109 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,8 @@
44
IMPORTANT: Indices created in Elasticsearch 6.0.0 or later may only contain a
55
single <<mapping-type,mapping type>>. Indices created in 5.x with multiple
66
mapping types will continue to function as before in Elasticsearch 6.x.
7-
Mapping types will be completely removed in Elasticsearch 7.0.0.
7+
Types will be deprecated in APIs in Elasticsearch 7.0.0, and completely
8+
removed in 8.0.0.
89

910
[float]
1011
=== What are mapping types?
@@ -256,30 +257,28 @@ Elasticsearch 6.x::
256257

257258
* The `_default_` mapping type is deprecated.
258259

260+
* In 6.7, the index creation, index template, and mapping APIs support a query
261+
string parameter (`include_type_name`) which indicates whether requests and
262+
responses should include a type name. It defaults to `true`, and not setting
263+
`include_type_name=false` will result in a deprecation warning. Indices which
264+
don't have an explicit type will use the dummy type name `_doc`.
265+
259266
Elasticsearch 7.x::
260267

261-
* The `type` parameter in URLs are deprecated. For instance, indexing
262-
a document no longer requires a document `type`. The new index APIs
268+
* Specifying types in requests is deprecated. For instance, indexing a
269+
document no longer requires a document `type`. The new index APIs
263270
are `PUT {index}/_doc/{id}` in case of explicit ids and `POST {index}/_doc`
264271
for auto-generated ids.
265272

266-
* The index creation, `GET|PUT _mapping` and document APIs support a query
267-
string parameter (`include_type_name`) which indicates whether requests and
268-
responses should include a type name. It defaults to `true`.
269-
7.x indices which don't have an explicit type will use the dummy type name
270-
`_doc`. Not setting `include_type_name=false` will result in a deprecation
271-
warning.
273+
* The `include_type_name` parameter in the index creation, index template,
274+
and mapping APIs will default to `false`. Setting the parameter will result
275+
in a deprecation warning.
272276

273277
* The `_default_` mapping type is removed.
274278

275279
Elasticsearch 8.x::
276280

277-
* The `type` parameter is no longer supported in URLs.
278-
279-
* The `include_type_name` parameter is deprecated, default to `false` and fails
280-
the request when set to `true`.
281-
282-
Elasticsearch 9.x::
281+
* Specifying types in requests is no longer supported.
283282

284283
* The `include_type_name` parameter is removed.
285284

@@ -425,7 +424,87 @@ POST _reindex
425424
// NOTCONSOLE
426425

427426
[float]
428-
=== Index templates
427+
=== Typeless APIs in 7.0
428+
429+
In Elasticsearch 7.0, each API will support typeless requests,
430+
and specifying a type will produce a deprecation warning. Certain
431+
typeless APIs are also available in 6.7, to enable a smooth upgrade
432+
path to 7.0.
433+
434+
[float]
435+
==== Indices APIs
436+
437+
Index creation, index template, and mapping APIs support a new `include_type_name`
438+
url parameter that specifies whether mapping definitions in requests and responses
439+
should contain the type name. The parameter defaults to `true` in version 6.7 to
440+
match the pre-7.0 behavior of using type names in mappings. It defaults to `false`
441+
in version 7.0 and will be removed in version 8.0.
442+
443+
See some examples of interactions with Elasticsearch with this option provided:
444+
445+
[source,js]
446+
--------------------------------------------------
447+
PUT index?include_type_name=false
448+
{
449+
"mappings": {
450+
"properties": { <1>
451+
"foo": {
452+
"type": "keyword"
453+
}
454+
}
455+
}
456+
}
457+
--------------------------------------------------
458+
// CONSOLE
459+
<1> Mappings are included directly under the `mappings` key, without a type name.
460+
461+
[source,js]
462+
--------------------------------------------------
463+
PUT index/_mappings?include_type_name=false
464+
{
465+
"properties": { <1>
466+
"bar": {
467+
"type": "text"
468+
}
469+
}
470+
}
471+
--------------------------------------------------
472+
// CONSOLE
473+
// TEST[continued]
474+
<1> Mappings are included directly under the `mappings` key, without a type name.
475+
476+
[source,js]
477+
--------------------------------------------------
478+
GET index/_mappings?include_type_name=false
479+
--------------------------------------------------
480+
// CONSOLE
481+
// TEST[continued]
482+
483+
The above call returns
484+
485+
[source,js]
486+
--------------------------------------------------
487+
{
488+
"index": {
489+
"mappings": {
490+
"properties": { <1>
491+
"foo": {
492+
"type": "keyword"
493+
},
494+
"bar": {
495+
"type": "text"
496+
}
497+
}
498+
}
499+
}
500+
}
501+
--------------------------------------------------
502+
// CONSOLE
503+
// TESTRESPONSE
504+
<1> Mappings are included directly under the `mappings` key, without a type name.
505+
506+
[float]
507+
==== Index templates
429508

430509
It is recommended to make index templates typeless before upgrading to 7.0 by
431510
re-adding them with `include_type_name` set to `false`.
@@ -495,5 +574,18 @@ PUT index-2-01?include_type_name=false
495574

496575
In case of implicit index creation, because of documents that get indexed in
497576
an index that doesn't exist yet, the template is always honored. This is
498-
usually not a problem due to the fact that typless index calls work on typed
577+
usually not a problem due to the fact that typeless index calls work on typed
499578
indices.
579+
580+
[float]
581+
==== Mixed-version clusters
582+
583+
In a cluster composed of both 6.7 and 7.0 nodes, the parameter
584+
`include_type_name` should be specified in indices APIs like index
585+
creation. This is because the parameter has a different default between
586+
6.7 and 7.0, so the same mapping definition will not be valid for both
587+
node versions.
588+
589+
Typeless document APIs such as `bulk` and `update` are only available as of
590+
7.0, and will not work with 6.7 nodes. This also holds true for the typeless
591+
versions of queries that perform document lookups, such as `terms`.

0 commit comments

Comments
 (0)