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.

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

Deprecate _type in simulate pipeline requests #37949

Merged
merged 15 commits into from
Feb 4, 2019

Conversation

gwbrown
Copy link
Contributor

@gwbrown gwbrown commented Jan 29, 2019

As mapping types are being removed throughout Elasticsearch, the use of
_type in pipeline simulation requests is deprecated.

Closes #37731

As mapping types are being removed throughout Elasticsearch, the use of
`_type` in pipeline simulation requests is deprecated.
@gwbrown gwbrown added >deprecation :Data Management/Ingest Node Execution or management of Ingest Pipelines including GeoIP v7.0.0 labels Jan 29, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

Copy link
Contributor

@jpountz jpountz left a comment

Choose a reason for hiding this comment

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

Thanks @gwbrown for tackling this.

if (dataMap.containsKey(MetaData.TYPE.getFieldName())) {
deprecationLogger.deprecatedAndMaybeLog("type_in_pipeline_simulation",
"Specifying _type in pipeline simulation requests is deprecated.");
}
String type = ConfigurationUtils.readStringOrIntProperty(null, null,
dataMap, MetaData.TYPE.getFieldName(), "_type");
Copy link
Contributor

Choose a reason for hiding this comment

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

we have been using _doc as a default type name elsewhere (there is a constant for it at MapperService.SINGLE_TYPE_NAME)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did notice that, but I wasn't sure if we wanted to switch it out here as this API has been using _type as the default for quite a while. What are your thoughts, @jakelandis?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to changing to _doc

@jakelandis
Copy link
Contributor

LGTM with a minor preference to use _doc as the default and explicitly test the both cases (as @jpountz comments)

"_id": "id",
"_source": {
"foo": "bar"
}
},
{
"_index": "index",
"_type": "_doc",
"_type": "_type",
Copy link
Contributor

@jakelandis jakelandis Jan 29, 2019

Choose a reason for hiding this comment

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

I would go ahead and remove the _type example here (and below) as well. We don't to encourage users to do anything with it.

Copy link
Contributor Author

@gwbrown gwbrown Jan 29, 2019

Choose a reason for hiding this comment

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

This is an example of the output of the call, which will have the _type field present. However, it looks like we can just provide null for the type to the IngestDocument if one isn't provided in the request and _type will be omitted from the response - what do you think of doing that instead of changing the default to _doc?

I've removed _type from all of the example inputs already.

Copy link
Contributor

Choose a reason for hiding this comment

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

However, it looks like we can just provide null for the type to the IngestDocument if one isn't provided in the request and _type will be omitted from the response - what do you think of doing that instead of changing the default to _doc

I think we should keep the "_type": "_doc" on the return values since it better mirrors the return of a typeless search

POST foo/_create/1
{}
GET foo/_search

Also, this line (164) is from the request, and there are some responses with it missing (for example 186-187).

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to @jakelandis's recommendation!

@gwbrown
Copy link
Contributor Author

gwbrown commented Jan 29, 2019

I've pushed changes that:

  1. Make the requested changes to tests,
  2. Omit _type entirely if it isn't provided in the request rather than providing a default, and
  3. Removed _type from the docs as appropriate per the change in 2).

How do folks feel about this as opposed to changing the default _type to _doc?

String type = ConfigurationUtils.readStringOrIntProperty(null, null,
dataMap, MetaData.TYPE.getFieldName(), "_type");
if (dataMap.containsKey(MetaData.TYPE.getFieldName())) {
deprecationLogger.deprecatedAndMaybeLog("type_in_pipeline_simulation",
Copy link
Contributor

@jtibshirani jtibshirani Jan 30, 2019

Choose a reason for hiding this comment

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

Small comment, but for consistency with our other logging statements it'd be nice to (1) use the key simulate_pipeline_with_types, and (2) prefix the warning message with [types removal]. Adding a prefix to messages was a bit unusual, but we needed a way to identify and ignore types-related warnings in tests.

"_id": "id",
"_source": {
"foo": "bar"
}
},
{
"_index": "index",
"_type": "_doc",
"_type": "_type",
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to @jakelandis's recommendation!

@jtibshirani
Copy link
Contributor

One note in addition to the small comments above: I think we'll need to update IngestClientDocumentationIT and IngestClientIT, as they currently make HLRC calls that reference _type.

Copy link
Contributor

@jakelandis jakelandis left a comment

Choose a reason for hiding this comment

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

Still LGTM !

@gwbrown gwbrown merged commit 292e0f6 into elastic:master Feb 4, 2019
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Feb 5, 2019
…-lease-expiration

* elastic/master: (24 commits)
  Add support for API keys to access Elasticsearch (elastic#38291)
  Add typless client side GetIndexRequest calls and response class (elastic#37778)
  Limit token expiry to 1 hour maximum (elastic#38244)
  add docs saying mixed-cluster ILM is not supported (elastic#37954)
  Skip unsupported languages for tests (elastic#38328)
  Deprecate `_type` in simulate pipeline requests (elastic#37949)
  Mute testCannotShrinkLeaderIndex (elastic#38374)
  Tighten mapping syncing in ccr remote restore (elastic#38071)
  Add test for `PutFollowAction` on a closed index (elastic#38236)
  Fix SSLContext pinning to TLSV1.2 in reload tests (elastic#38341)
  Mute RareClusterStateIT.testDelayedMappingPropagationOnReplica (elastic#38357)
  Deprecate types in rollover index API (elastic#38039)
  Types removal - fix FullClusterRestartIT warning expectations (elastic#38310)
  Fix ILM explain response to allow unknown fields (elastic#38054)
  Mute testFollowIndexAndCloseNode (elastic#38360)
  Docs: Drop inline callout from scroll example (elastic#38340)
  Deprecate HLRC security methods (elastic#37883)
  Remove types from Monitoring plugin "backend" code (elastic#37745)
  Add Composite to AggregationBuilders (elastic#38207)
  Clarify slow cluster-state log messages (elastic#38302)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/Ingest Node Execution or management of Ingest Pipelines including GeoIP >deprecation v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants