-
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
[REST Compatible API] Typed endpoints for Index and Get APIs #69131
Conversation
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.
LGTM - a couple of nits but otherwise good to go.
} | ||
|
||
@Override | ||
public String getName() { | ||
return "document_index_action"; | ||
} | ||
|
||
public static final class CreateHandler extends RestIndexAction { | ||
public static class CreateHandler extends RestIndexAction { |
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 think these can stay as final
now?
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.
yes, these should be final. will fix
@@ -70,7 +86,7 @@ void validateOpType(String opType) { | |||
} | |||
} | |||
|
|||
public static final class AutoIdHandler extends RestIndexAction { | |||
public static class AutoIdHandler extends RestIndexAction { |
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.
And here
@@ -388,6 +388,7 @@ void checkWarningHeaders(final List<String> warningHeaders, final Version master | |||
final boolean matches = matcher.matches(); | |||
if (matches) { | |||
final String message = HeaderWarning.extractWarningValueFromWarningHeader(header, true); | |||
|
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.
nit: can remove this
// DocWriteResponse is abstract so we have to sneak a subclass in here to test it. | ||
}; | ||
try (XContentBuilder builder = JsonXContent.contentBuilder()) { | ||
builder.withCompatibleVersion(RestApiVersion.V_7); |
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'm a bit uneasy that we can just change the compatible version on the XContentBuilder at any time, as that means that a consumer could change it accidentally; I think I'd prefer that it's a parameter passed to contentBuilder()
. But that's not really part of this issue, so we can look at it separately.
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 agree, these should be fixed, but also feel that this should be in a separate PR. The change might require touching many files and would be unrelated to the index/get api.
I will follow up in a separate PR
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.
also take a look at https://github.com/elastic/elasticsearch/pull/64423/files#r518884033
we try to prevent accidental change of the version with the assert
inside withCompatibleVersion
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.
+1 to making it immutable or explicitly 'set once', that would clearly indicate the intent that it should never be updated.
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 refactored the XContentBuilder to have this field final and set in a constructor #70878
@elasticmachine update branch |
|
||
import static org.hamcrest.Matchers.instanceOf; | ||
|
||
public class RestGetActionTests extends RestActionTestCase { |
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.
hmm... this will fail when master is on version 9. Can we add an assumeTrue(RestApiVersion.current() == 8) ..or something like that, also with a note to delete in v9+
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 RestApiVersion.V_7
exist in master at all? Often dead code like this is removed on upgrade because the constants that it uses for guards are deleted, in which case this test class will fail to compile.
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.
@romseygeek that is the plan. Once the RestApiVersion.V_7
is deleted, we will delete the tests using it.
However we don't want to create a blocker during the upgrade process and we expect for a brief period of time RestApiVersion will have V_7 (obsolete) V_8 compatible and V_9 current.
@@ -84,4 +91,34 @@ private void checkAutoIdOpType(Version minClusterVersion, DocWriteRequest.OpType | |||
dispatchRequest(autoIdRequest); | |||
assertThat(executeCalled.get(), equalTo(true)); | |||
} | |||
|
|||
public void testTypeInPath() { |
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.
same comment here about failing on version 9
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 one is actually tricky.
This test is testing both compatible and current version behaviour. The RestIndexAction will be registered using its all routes, including the compatible routes. After the version bump, when the V_7 is obsolete the test will fail in setUpAction
because of the assert in the RestController:L179
assert RestApiVersion.minimumSupported() == version || RestApiVersion.current() == version
: "REST API compatibility is only supported for version " + RestApiVersion.minimumSupported().major;
I guess I will move the compat tests into separate file and use the assert there?
although hmm this won't help..
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 only thing that comes to mind is to have a strategy that we only bump the minimumSupported/current versions when all of the V_7 code is removed..
But that is also against whet we already assumed and had assertions in place
Version:L124
assert RestApiVersion.current().major == CURRENT.major : "RestApiVersion must be upgraded " +
"to reflect major from Version.CURRENT [" + CURRENT.major + "]" +
" but is still set to [" + RestApiVersion.current().major + "]";
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.
all in all this feels bigger then just a small fix and deserves a separate follow up PR - there is plenty of time before 8 actually being released
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'm sure I completely follow, but i am fine with follow ups later on to help enusre the bump to v9 is easier.
However, I think adding in an assumeTrue per Test that shouldn't run in v9 is pretty easy to implement now..but if I am wrong +1 for followup.
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.
as per discussion on the sync, I gathered the conclusions on the issue #70617
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.
LGTM , however we should protect the tests from running (and failing) on v9. Either in this PR or a followup.
@@ -40,6 +42,9 @@ | |||
|
|||
public class GetResult implements Writeable, Iterable<DocumentField>, ToXContentObject { | |||
|
|||
private static final String TYPE_FIELD_NAME = "_type"; | |||
private static final Text SINGLE_MAPPING_TYPE = new Text(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.
Small comment, I think we can use MapperService.SINGLE_MAPPING_NAME
directly and avoid this extra constant.
|
||
public class RestGetActionTests extends RestActionTestCase { | ||
final List<String> contentTypeHeader = | ||
Collections.singletonList("application/vnd.elasticsearch+json;compatible-with="+ RestApiVersion.V_7.major); |
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.
Small comment, is there a way to avoid hardcoding this header in every test?
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.
good point, there is randomCompatibleMediaType
in ESTestCase`
// DocWriteResponse is abstract so we have to sneak a subclass in here to test it. | ||
}; | ||
try (XContentBuilder builder = JsonXContent.contentBuilder()) { | ||
builder.withCompatibleVersion(RestApiVersion.V_7); |
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.
+1 to making it immutable or explicitly 'set once', that would clearly indicate the intent that it should never be updated.
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 approach looks good to me too! I like the targeted checks, they keep the structure simple and don't hurt readability too much. Also the test coverage looks good.
@elasticmachine update branch |
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 types removal effort has removed the
type
from Index API in #47671 and from Get API in #46587This commit allows to use 'typed' endpoints for the both Index and Get APIs
relates compatible types-removal meta issue #54160