Modify removal_of_types.asciidoc #37648

cbuescher · 2019-01-21T10:06:27Z

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.

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.

elasticmachine · 2019-01-21T10:06:30Z

Pinging @elastic/es-search

mayya-sharipova

@cbuescher Thanks Christoph. Some minor changes requested.

Also, Looks like the paragraph about include_type_name in 7.x is incorrect, we should correct it as well. It says: "It defaults to true.... Not setting include_type_name=false will result in a deprecation
warning." But should say "It defaults to false.... Using a parameter include_type_name with either false or true value will result in a deprecation warning."

mayya-sharipova · 2019-01-21T21:20:13Z

docs/reference/mapping/removal_of_types.asciidoc

@@ -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


should we remove _doc type on line 310?

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.

mayya-sharipova · 2019-01-21T21:20:56Z

docs/reference/mapping/removal_of_types.asciidoc

@@ -321,7 +323,7 @@ PUT users?include_type_name=true
  }
 }

-PUT tweets?include_type_name=true
+PUT tweets


should we remove _doc type on line 322?

same reason as before

mayya-sharipova · 2019-01-21T21:21:32Z

docs/reference/mapping/removal_of_types.asciidoc

@@ -376,7 +378,7 @@ documents of different types which have conflicting IDs:

 [source,js]
 ----
-PUT new_twitter?include_type_name=true
+PUT new_twitter


should we remove _doc type on line 384?

same reason as before

mayya-sharipova · 2019-01-21T21:31:22Z

docs/reference/mapping/removal_of_types.asciidoc

+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.
+


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

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.'

jtibshirani

Thanks a lot @cbuescher for tackling this, I had been meaning to update this page after we revised the deprecation plan. Building on @mayya-sharipova's review, I think we should update the section on Schedule for removal of mapping types’ to mention that the include_type_nameparameter will be introduced in 6.7 for mapping-related APIs, default tofalse` in 7.0, and be removed in 8.0.

I also think that we'll need to update the section on Document APIs and also that we should likely add an additional section on some of the other deprecations (for example the 'explain endpoint changing from {index}/{type}/{id}/_explain to {index}/_explain/{id}). However, this would be totally fine for one of us to do in a subsequent PR if you'd like to keep this one scoped to include_type_name.

jtibshirani · 2019-01-21T22:06:46Z

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


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.'

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.

jtibshirani · 2019-01-21T22:27:03Z

docs/reference/mapping/removal_of_types.asciidoc

+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.
+


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.'

cbuescher · 2019-01-22T10:50:04Z

@mayya-sharipova @jtibshirani thanks for the comments. I agree this page should be reworked again after we finish the deprecation work. The changes I made were intended to only target the use of "include_type_name=true" in the documentation snippets. Since it is unclear for several code snippets which ES version they are meant to be run on (some use two type-names still) I think we should generally stick with the old typed request bodies in most places. I updated the PR accordingly. Please take another look.

jtibshirani

This looks good to me as well, with the understanding that one of us will rework this documentation in a follow-up.

mayya-sharipova · 2019-01-22T21:22:57Z

@cbuescher thanks Christoph, LGTM

…ead-de-duplication * elastic/master: (24 commits) [TEST] Mute MlMappingsUpgradeIT testMappingsUpgrade Streamline skip_unavailable handling (elastic#37672) Only bootstrap and elect node in current voting configuration (elastic#37712) Ensure either success or failure path for SearchOperationListener is called (elastic#37467) Target only specific index in update settings test Add a note how to benchmark Elasticsearch Don't use Groovy's `withDefault` (elastic#37726) Adapt SyncedFlushService (elastic#37691) Mute FilterAggregatorTests#testRandom Switch mapping/aggregations over to java time (elastic#36363) [ML] Update ML results mappings on process start (elastic#37706) Modify removal_of_types.asciidoc (elastic#37648) Fix edge case in PutMappingRequestTests (elastic#37665) Use new bulk API endpoint in the docs (elastic#37698) Expose sequence number and primary terms in search responses (elastic#37639) Remove LicenseServiceClusterNotRecoveredTests (elastic#37528) Migrate SpecificMasterNodesIT to Zen2 (elastic#37532) Fix MetaStateFormat tests Use plain text instead of latexmath Fix a typo in a warning message in TestFixturesPlugin (elastic#37631) ...

Modify removal_of_types.asciidoc

9f3a360

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.

cbuescher added >docs General docs changes :Search Foundations/Mapping Index mappings, including merging and defining field types v7.0.0 >refactoring labels Jan 21, 2019

cbuescher requested review from jpountz and jtibshirani January 21, 2019 10:06

mayya-sharipova approved these changes Jan 21, 2019

View reviewed changes

jtibshirani reviewed Jan 21, 2019

View reviewed changes

iteration

17f4678

jtibshirani approved these changes Jan 22, 2019

View reviewed changes

cbuescher merged commit b3f9bec into elastic:master Jan 23, 2019

jtibshirani mentioned this pull request Jan 23, 2019

Implementation tracking for 7.0 types deprecation. #35190

Closed

48 tasks

colings86 added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Modify removal_of_types.asciidoc #37648

Modify removal_of_types.asciidoc #37648

cbuescher commented Jan 21, 2019

elasticmachine commented Jan 21, 2019

mayya-sharipova left a comment

mayya-sharipova Jan 21, 2019

cbuescher Jan 22, 2019

mayya-sharipova Jan 21, 2019

cbuescher Jan 22, 2019

mayya-sharipova Jan 21, 2019

cbuescher Jan 22, 2019

mayya-sharipova Jan 21, 2019

jtibshirani Jan 21, 2019

jtibshirani left a comment

jtibshirani Jan 21, 2019

cbuescher Jan 22, 2019

jtibshirani Jan 21, 2019

cbuescher commented Jan 22, 2019

jtibshirani left a comment

mayya-sharipova commented Jan 22, 2019

Modify removal_of_types.asciidoc #37648

Modify removal_of_types.asciidoc #37648

Conversation

cbuescher commented Jan 21, 2019

elasticmachine commented Jan 21, 2019

mayya-sharipova left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jtibshirani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbuescher commented Jan 22, 2019

jtibshirani left a comment

Choose a reason for hiding this comment

mayya-sharipova commented Jan 22, 2019