-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Conversation
Pinging @elastic/es-search-aggs |
3a9af44
to
1083631
Compare
I'm wondering whether that would be
+1 |
@jpountz in terms of swapping |
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? |
1083631
to
c7740d8
Compare
After discussion, we've decided to go with the endpoint format Removing the type component (as in
|
c7740d8
to
7a6f3db
Compare
@elasticmachine test this please |
There was a problem hiding this 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"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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]")) { |
There was a problem hiding this comment.
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
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)); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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 namesome_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'.