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 types in explain requests. #35611

Merged
merged 4 commits into from
Dec 11, 2018

Conversation

jtibshirani
Copy link
Contributor

This PR introduces the new untyped endpoint {index}/{id}/_explain, and deprecates {index}/{type}/{id}/_explain.

Note that we currently have the following issue: if a document is created with type some_type, and we make an untyped explain request for that document, then it will not be found. This is because an untyped explain request uses the dummy type _doc, which does not match the existing type name some_type.

I didn't address the issue in this PR, since I suspect we want to step back and approach it more generally. Tagging @jpountz here, since he was planning to look into how to address this 'types mismatch'.

@jtibshirani jtibshirani added :Search Foundations/Mapping Index mappings, including merging and defining field types >deprecation v7.0.0 labels Nov 16, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@jpountz
Copy link
Contributor

jpountz commented Nov 16, 2018

{index}/{id}/_explain

I'm wondering whether that would be {index}/_explain/{id} instead, similarly to {index}/_doc/{id}.

I didn't address the issue in this PR, since I suspect we want to step back and approach it more generally

+1

@pcsanwald
Copy link
Contributor

@jpountz in terms of swapping _explain/{id} for {id}/_explain, I feel we should address API consistency issues separately, unless we intend to address them all as part of this initiative. In terms of explaining to users what types removal means for them, it's much clearer if we are able to explain that in order types removal means they should remove the type name from the path where it is used. This feels like a much clearer explanation to me, and if I was auditing my app in preparation for a 7.0 upgrade, it would be way easier for me to assess the impact, vs this change and in addition, other path parameter changes.

@jtibshirani
Copy link
Contributor Author

Thanks @jpountz and @pcsanwald, I opened an internal issue to try to get more clarity on this and other related points -- maybe we could move the discussion there for now, then I will report back here with our conclusions?

@jtibshirani
Copy link
Contributor Author

jtibshirani commented Dec 10, 2018

After discussion, we've decided to go with the endpoint format {index}/_explain/{id}. I've updated the PR to use this format.

Removing the type component (as in {index}/{id}/_explain) didn’t seem viable, because

  • Unlike types, IDs are allowed to contain underscores, and there could be collisions with other endpoints like {index}/_doc/{id}.
  • It doesn’t work cleanly for all URLs, for example 'termvectors' where it introduces collisions between the different endpoints.

@jtibshirani
Copy link
Contributor Author

@elasticmachine test this please

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.

I left some comments but it looks good in general. Thanks for tackling this!

endpoint(explainRequest.index(), explainRequest.type(), explainRequest.id(), "_explain"));
String endpoint = explainRequest.isTypeless()
? endpoint(explainRequest.index(), "_explain", explainRequest.id())
: endpoint(explainRequest.index(), explainRequest.id(), "_explain");
Copy link
Contributor

Choose a reason for hiding this comment

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

I would expect to have explainRequest.type() somewhere on this line?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops, I think I have been staring at this too long...

@@ -1225,10 +1225,12 @@ public void testMultiSearchTemplate() throws Exception {

public void testExplain() throws IOException {
String index = randomAlphaOfLengthBetween(3, 10);
String type = randomAlphaOfLengthBetween(3, 10);
String type = randomBoolean() ? null : randomAlphaOfLengthBetween(3, 10);
Copy link
Contributor

Choose a reason for hiding this comment

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

let's test both cases all the time?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do, that would've helped catch the issue above.

@@ -7,7 +7,7 @@ This can give useful feedback whether a document matches or didn’t match a spe
[[java-rest-high-explain-request]]
==== Explain Request

An `ExplainRequest` expects an `index`, a `type` and an `id` to specify a certain document,
An `ExplainRequest` expects an `index`, and an `id` to specify a certain document,
Copy link
Contributor

Choose a reason for hiding this comment

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

remove comma after id?

public ExplainRequest type(String type) {
this.type = type;
return this;
}

public boolean isTypeless() {
return type.equals(MapperService.SINGLE_MAPPING_NAME);
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 protect against NPE?

@Override
public boolean warningsShouldFailRequest(List<String> warnings) {
for (String warning : warnings) {
if (!warning.startsWith("[types removal]")) {
Copy link
Contributor

Choose a reason for hiding this comment

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

the more common idiom across the code base is to do == false

@jtibshirani
Copy link
Contributor Author

Thanks @jpountz for the review! I've tried to address your comments.

RequestOptions.Builder explanationOptions = RequestOptions.DEFAULT.toBuilder();
explanationOptions.setWarningsHandler(TypesRemovalWarningsHandler.INSTANCE);
explanationRequest.setOptions(explanationOptions);

String explanation = toStr(client().performRequest(explanationRequest));
Copy link
Contributor

Choose a reason for hiding this comment

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

This style of warnings handler helps suppress test failures but does not help assert that any of the expected warnings are actually being returned.
The #36443 PR aims to provide a WarningsHandler that can require the expected warnings materialise (given a same-version cluster) or are allowed in a multi-version cluster

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @markharwood, that looks like a nice addition. In the next CRUD deprecation PR, maybe we can try migrating to that approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

An update: In #36511 I tried switching to the VersionSensitiveWarningsHandler introduced in that PR. I'd be curious to get your feedback on how it's being used.

@colings86 colings86 removed the v7.0.0 label Feb 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>deprecation :Search Foundations/Mapping Index mappings, including merging and defining field types v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants