From 9f3a36007a5aa77aa378ad1bcfa1ce054bd8b7a3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christoph=20B=C3=BCscher?= Date: Mon, 21 Jan 2019 11:03:11 +0100 Subject: [PATCH 1/2] Modify removal_of_types.asciidoc After switching the default behaviour of "include_type_name" to "false" in 7.0, some parts of the types removal documentation can be adapted as well. --- .../mapping/removal_of_types.asciidoc | 35 +++++++++++-------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/docs/reference/mapping/removal_of_types.asciidoc b/docs/reference/mapping/removal_of_types.asciidoc index 251025c1ba24c..4485f93e3c59d 100644 --- a/docs/reference/mapping/removal_of_types.asciidoc +++ b/docs/reference/mapping/removal_of_types.asciidoc @@ -157,22 +157,24 @@ GET twitter/tweet/_search ---- // NOTCONSOLE +Note the use of the `include_type_name=true` url parameter on index creation. +This is necessary as the use of types is deprecated in 7.0. In this example +it is solely used to force the legacy behaviour. + You could achieve the same thing by adding a custom `type` field as follows: [source,js] ---- -PUT twitter?include_type_name=true +PUT twitter { "mappings": { - "_doc": { - "properties": { - "type": { "type": "keyword" }, <1> - "name": { "type": "text" }, - "user_name": { "type": "keyword" }, - "email": { "type": "keyword" }, - "content": { "type": "text" }, - "tweeted_at": { "type": "date" } - } + "properties": { + "type": { "type": "keyword" }, <1> + "name": { "type": "text" }, + "user_name": { "type": "keyword" }, + "email": { "type": "keyword" }, + "content": { "type": "text" }, + "tweeted_at": { "type": "date" } } } } @@ -299,7 +301,7 @@ This first example splits our `twitter` index into a `tweets` index and a [source,js] ---- -PUT users?include_type_name=true +PUT users { "settings": { "index.mapping.single_type": true @@ -321,7 +323,7 @@ PUT users?include_type_name=true } } -PUT tweets?include_type_name=true +PUT tweets { "settings": { "index.mapping.single_type": true @@ -376,7 +378,7 @@ documents of different types which have conflicting IDs: [source,js] ---- -PUT new_twitter?include_type_name=true +PUT new_twitter { "mappings": { "_doc": { @@ -429,8 +431,11 @@ POST _reindex Index creation, mappings and document APIs support the `include_type_name` option. When set to `false`, this option enables the behavior that will become -default in 8.0 when types are removed. See some examples of interactions with -Elasticsearch with this option turned off: +default in 8.0 when types are removed. Since the default for `include_type_name` +is `false` starting with 7.0, you can omit using it after 7.0, but you can use +it in case you want to temporarily force the legacy behaviour. + +See some examples of interactions with Elasticsearch with this option turned off: [float] ==== Index creation From 17f467885dc0348c843e13b0fcb3cbe3768ddaf5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christoph=20B=C3=BCscher?= Date: Tue, 22 Jan 2019 11:47:01 +0100 Subject: [PATCH 2/2] iteration --- .../mapping/removal_of_types.asciidoc | 41 +++++++++---------- 1 file changed, 20 insertions(+), 21 deletions(-) diff --git a/docs/reference/mapping/removal_of_types.asciidoc b/docs/reference/mapping/removal_of_types.asciidoc index 4485f93e3c59d..ee5ee4b4fe664 100644 --- a/docs/reference/mapping/removal_of_types.asciidoc +++ b/docs/reference/mapping/removal_of_types.asciidoc @@ -112,7 +112,7 @@ have looked something like this: [source,js] ---- -PUT twitter?include_type_name=true +PUT twitter { "mappings": { "user": { @@ -157,24 +157,22 @@ GET twitter/tweet/_search ---- // NOTCONSOLE -Note the use of the `include_type_name=true` url parameter on index creation. -This is necessary as the use of types is deprecated in 7.0. In this example -it is solely used to force the legacy behaviour. - -You could achieve the same thing by adding a custom `type` field as follows: +You can achieve the same thing by adding a custom `type` field as follows: [source,js] ---- -PUT twitter +PUT twitter?include_type_name=true <1> { "mappings": { - "properties": { - "type": { "type": "keyword" }, <1> - "name": { "type": "text" }, - "user_name": { "type": "keyword" }, - "email": { "type": "keyword" }, - "content": { "type": "text" }, - "tweeted_at": { "type": "date" } + "_doc": { + "properties": { + "type": { "type": "keyword" }, <2> + "name": { "type": "text" }, + "user_name": { "type": "keyword" }, + "email": { "type": "keyword" }, + "content": { "type": "text" }, + "tweeted_at": { "type": "date" } + } } } } @@ -206,7 +204,7 @@ GET twitter/_search }, "filter": { "match": { - "type": "tweet" <1> + "type": "tweet" <2> } } } @@ -214,7 +212,9 @@ GET twitter/_search } ---- // NOTCONSOLE -<1> The explicit `type` field takes the place of the implicit `_type` field. +<1> Use `include_type_name=true` in case need to use the "old" syntax including the "_doc" object like +in this example +<2> The explicit `type` field takes the place of the implicit `_type` field. [float] ==== Parent/Child without mapping types @@ -429,11 +429,10 @@ POST _reindex [float] === Use `include_type_name=false` to prepare for upgrade to 8.0 -Index creation, mappings and document APIs support the `include_type_name` -option. When set to `false`, this option enables the behavior that will become -default in 8.0 when types are removed. Since the default for `include_type_name` -is `false` starting with 7.0, you can omit using it after 7.0, but you can use -it in case you want to temporarily force the legacy behaviour. +Index creation and mapping APIs support a new `include_type_name` url parameter +starting with version 6.7. It will default to `true` in version 6.7, default to +`false` in version 7.0 and will be removed in version 8.0. When set to `true`, +this parameter enables the pre-7.0 behavior of using type names in the API. See some examples of interactions with Elasticsearch with this option turned off: