Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 20 additions & 15 deletions docs/reference/mapping/removal_of_types.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small suggestion: instead of 'This is necessary as the use of types is deprecated in 7.0.', we could say 'This is necessary because index creation requests are typeless by default in 7.0.'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, now thinking about it, the example uses two types still and is only there to exemplify the "old" syntax. It shoudln't use "include_type_names" at all and is also not run in the tests (//NOTCONSOLE) so I think we should remove this note again and also remove the parameter here, since it can only work in 5.6 indices this way.

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" }
}
}
}
Expand Down Expand Up @@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we remove _doc type on line 310?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this example ment to be execute on either 5.6 or 6.x. to split a multiple-type index moving forward. So the new syntax doesn't apply there yet.

{
"settings": {
"index.mapping.single_type": true
Expand All @@ -321,7 +323,7 @@ PUT users?include_type_name=true
}
}

PUT tweets?include_type_name=true
PUT tweets
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we remove _doc type on line 322?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same reason as before

{
"settings": {
"index.mapping.single_type": true
Expand Down Expand Up @@ -376,7 +378,7 @@ documents of different types which have conflicting IDs:

[source,js]
----
PUT new_twitter?include_type_name=true
PUT new_twitter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we remove _doc type on line 384?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same reason as before

{
"mappings": {
"_doc": {
Expand Down Expand Up @@ -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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be we can phrase this paragraph simpler, removing the sentence "When set to false, this option enables the behavior that will become.."?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to @mayya-sharipova's point, I think this whole paragraph will need to be reworked a bit, since we have changed the plan significantly since it was written:

  • It is only index/ mapping APIs that support this parameter now (not document APIs).
  • It would be good to mention that this parameter is introduced in 6.7 with a default of true, and then will be defaulted to false in 7.0 and removed in 8.0. In particular, I think it is a little confusing to say '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:

[float]
==== Index creation
Expand Down