Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify removal_of_types.asciidoc #37648

Merged
merged 2 commits into from
Jan 23, 2019
Merged

Modify removal_of_types.asciidoc #37648

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9f3a360
Modify removal_of_types.asciidoc
Jan 21, 2019
17f4678
iteration
Jan 22, 2019
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
30 changes: 17 additions & 13 deletions docs/reference/mapping/removal_of_types.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,7 +112,7 @@ have looked something like this:

[source,js]
----
PUT twitter?include_type_name=true
PUT twitter
{
"mappings": {
"user": {
Expand Down Expand Up @@ -157,16 +157,16 @@ GET twitter/tweet/_search
----
// NOTCONSOLE

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?include_type_name=true
PUT twitter?include_type_name=true <1>
{
"mappings": {
"_doc": {
"properties": {
"type": { "type": "keyword" }, <1>
"type": { "type": "keyword" }, <2>
"name": { "type": "text" },
"user_name": { "type": "keyword" },
"email": { "type": "keyword" },
Expand Down Expand Up @@ -204,15 +204,17 @@ GET twitter/_search
},
"filter": {
"match": {
"type": "tweet" <1>
"type": "tweet" <2>
}
}
}
}
}
----
// 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
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 @@ -427,10 +429,12 @@ 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. See some examples of interactions with
Elasticsearch with this option turned off:
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.

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