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

REST test for typeless APIs. #33934

Merged
merged 4 commits into from
Sep 26, 2018

Conversation

jpountz
Copy link
Contributor

@jpountz jpountz commented Sep 21, 2018

This commit duplicates REST tests for the

  • indices.create
  • indices.put_mapping
  • indices.get_mapping
  • index
  • get
  • delete
  • update
  • bulk
    APIs, so that we both test them when used without types (include_type_name=false)
    and with types, mostly for mixed-version cluster tests.

Given a suite called X_test_name.yml, I first copied it to
(X+1)_test_name_legacy.yml and then changed X_test_name.yml to set
include_type_name=false on every API that supports it.

Relates #15613

This commit duplicates REST tests for the
 - `indices.create`
 - `indices.put_mapping`
 - `indices.get_mapping`
 - `index`
 - `get`
 - `delete`
 - `update`
 - `bulk`
APIs, so that we both test them when used without types (include_type_name=false)
and with types, mostly for mixed-version cluster tests.

Given a suite called `X_test_name.yml`, I first copied it to
`(X+1)_test_name_legacy.yml` and then changed `X_test_name.yml` to set
`include_type_name=false` on every API that supports it.

Relates elastic#15613
@jpountz jpountz added >test Issues or PRs that are addressing/adding tests :Search Foundations/Mapping Index mappings, including merging and defining field types v7.0.0 labels Sep 21, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

if (parser.nextToken() != XContentParser.Token.START_OBJECT) {
throw new XContentParseException(parser.getTokenLocation(),
"expected token to be START_OBJECT but was " + parser.currentToken());
}
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 hit this assertion during development, which was not nice because it doesn't tell the line/offset of the problem, so I switched to a hard check that also gives the location of the parsing error.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

Copy link
Member

Choose a reason for hiding this comment

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

++

Copy link
Contributor

@jtibshirani jtibshirani left a comment

Choose a reason for hiding this comment

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

It looks good to me, just some minor comments.

One overall thought (also minor): I wonder if _with_types would be more descriptive than _legacy? Alternatively, we could add a quick note to the testing README.

if (parser.nextToken() != XContentParser.Token.START_OBJECT) {
throw new XContentParseException(parser.getTokenLocation(),
"expected token to be START_OBJECT but was " + parser.currentToken());
}
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@@ -0,0 +1,33 @@
---
"Metadata Fields":
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is missing a corresponding change in the non-legacy version (only noticed this because it's last).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, I missed it because it is currently disabled due to a bug.

@@ -0,0 +1,46 @@
---
"No type returned":
Copy link
Contributor

Choose a reason for hiding this comment

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

To check I'm following -- this is our approach for the testing search API (as opposed to duplicating the REST tests, as we do for other APIs)? This test also got me thinking that we should probably deprecate/ disallow type queries.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I wanted to mention it and then forgot.

The reason why I added this test here is that we used to have tests for a couple APIs without types under put_mapping including this test for _search, and I didn't want to lose it.

I still need to think a bit about search. Some tests would be worth migrating for sure, eg. search.highlight and search.inner_hits. I'm less sure about search.aggregations since the output is not affected by the change? I'm keeping _search for later as I felt that this PR was already pretty large and added good coverage.

For the record, there are other APIs that we still need to make typeless like _explain (it doesn't support the include_type_name flag yet) so we will need to duplicate tests for it as well.

Copy link
Member

Choose a reason for hiding this comment

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

Does this mean that for _search, include_type_name=false means that _type should not be returned as part of the hits? Does the flag do anything else for _search?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@javanna No, this is all it does indeed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test also got me thinking that we should probably deprecate/ disallow type queries.

They are already deprecated: #29468

Copy link
Contributor

@jtibshirani jtibshirani Sep 24, 2018

Choose a reason for hiding this comment

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

Thanks for the explanation. Addressed my confusion about the type query deprecation in #34017 :)

@jpountz
Copy link
Contributor Author

jpountz commented Sep 24, 2018

@jtibshirani Thanks for the review, I rename *_legacy to *_with_types to make file names more descriptive as suggested.

@jpountz
Copy link
Contributor Author

jpountz commented Sep 24, 2018

@elasticmachine test this please

@jpountz jpountz merged commit 3c2841d into elastic:master Sep 26, 2018
@jpountz jpountz deleted the include_type_name_rest_tests branch September 26, 2018 15:11
kcm pushed a commit that referenced this pull request Oct 30, 2018
This commit duplicates REST tests for the
 - `indices.create`
 - `indices.put_mapping`
 - `indices.get_mapping`
 - `index`
 - `get`
 - `delete`
 - `update`
 - `bulk`
APIs, so that we both test them when used without types (include_type_name=false)
and with types, mostly for mixed-version cluster tests.

Given a suite called `X_test_name.yml`, I first copied it to
`(X+1)_test_name_with_types.yml` and then changed `X_test_name.yml` to set
`include_type_name=false` on every API that supports it.

Relates #15613
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Search Foundations/Mapping Index mappings, including merging and defining field types >test Issues or PRs that are addressing/adding tests v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants