@@ -112,7 +112,7 @@ have looked something like this:
112112
113113[source,js]
114114----
115- PUT twitter?include_type_name=true
115+ PUT twitter
116116{
117117 "mappings": {
118118 "user": {
@@ -157,16 +157,16 @@ GET twitter/tweet/_search
157157----
158158// NOTCONSOLE
159159
160- You could achieve the same thing by adding a custom `type` field as follows:
160+ You can achieve the same thing by adding a custom `type` field as follows:
161161
162162[source,js]
163163----
164- PUT twitter?include_type_name=true
164+ PUT twitter?include_type_name=true <1>
165165{
166166 "mappings": {
167167 "_doc": {
168168 "properties": {
169- "type": { "type": "keyword" }, <1 >
169+ "type": { "type": "keyword" }, <2 >
170170 "name": { "type": "text" },
171171 "user_name": { "type": "keyword" },
172172 "email": { "type": "keyword" },
@@ -204,15 +204,17 @@ GET twitter/_search
204204 },
205205 "filter": {
206206 "match": {
207- "type": "tweet" <1 >
207+ "type": "tweet" <2 >
208208 }
209209 }
210210 }
211211 }
212212}
213213----
214214// NOTCONSOLE
215- <1> The explicit `type` field takes the place of the implicit `_type` field.
215+ <1> Use `include_type_name=true` in case need to use the "old" syntax including the "_doc" object like
216+ in this example
217+ <2> The explicit `type` field takes the place of the implicit `_type` field.
216218
217219[float]
218220==== Parent/Child without mapping types
@@ -299,7 +301,7 @@ This first example splits our `twitter` index into a `tweets` index and a
299301
300302[source,js]
301303----
302- PUT users?include_type_name=true
304+ PUT users
303305{
304306 "settings": {
305307 "index.mapping.single_type": true
@@ -321,7 +323,7 @@ PUT users?include_type_name=true
321323 }
322324}
323325
324- PUT tweets?include_type_name=true
326+ PUT tweets
325327{
326328 "settings": {
327329 "index.mapping.single_type": true
@@ -376,7 +378,7 @@ documents of different types which have conflicting IDs:
376378
377379[source,js]
378380----
379- PUT new_twitter?include_type_name=true
381+ PUT new_twitter
380382{
381383 "mappings": {
382384 "_doc": {
@@ -427,10 +429,12 @@ POST _reindex
427429[float]
428430=== Use `include_type_name=false` to prepare for upgrade to 8.0
429431
430- Index creation, mappings and document APIs support the `include_type_name`
431- option. When set to `false`, this option enables the behavior that will become
432- default in 8.0 when types are removed. See some examples of interactions with
433- Elasticsearch with this option turned off:
432+ Index creation and mapping APIs support a new `include_type_name` url parameter
433+ starting with version 6.7. It will default to `true` in version 6.7, default to
434+ `false` in version 7.0 and will be removed in version 8.0. When set to `true`,
435+ this parameter enables the pre-7.0 behavior of using type names in the API.
436+
437+ See some examples of interactions with Elasticsearch with this option turned off:
434438
435439[float]
436440==== Index creation
0 commit comments