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 Compatible API] Typed endpoints for Index and Get APIs #69131

Merged
merged 52 commits into from
Mar 23, 2021

Conversation

pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Feb 17, 2021

The types removal effort has removed the type from Index API in #47671 and from Get API in #46587

This commit allows to use 'typed' endpoints for the both Index and Get APIs

relates compatible types-removal meta issue #54160

@pgomulka pgomulka mentioned this pull request Mar 17, 2021
66 tasks
Copy link
Contributor

@romseygeek romseygeek left a 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 {
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 these can stay as final now?

Copy link
Contributor Author

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 {
Copy link
Contributor

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);

Copy link
Contributor

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);
Copy link
Contributor

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.

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 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

Copy link
Contributor Author

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

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 making it immutable or explicitly 'set once', that would clearly indicate the intent that it should never be updated.

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 refactored the XContentBuilder to have this field final and set in a constructor #70878

@pgomulka
Copy link
Contributor Author

@elasticmachine update branch


import static org.hamcrest.Matchers.instanceOf;

public class RestGetActionTests extends RestActionTestCase {
Copy link
Contributor

@jakelandis jakelandis Mar 18, 2021

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+

Copy link
Contributor

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.

Copy link
Contributor Author

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() {
Copy link
Contributor

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

Copy link
Contributor Author

@pgomulka pgomulka Mar 18, 2021

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..

Copy link
Contributor Author

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 + "]";

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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

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.

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);
Copy link
Contributor

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);
Copy link
Contributor

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?

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 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);
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 making it immutable or explicitly 'set once', that would clearly indicate the intent that it should never be updated.

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.

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.

@pgomulka
Copy link
Contributor Author

@elasticmachine update branch

Copy link
Contributor

@joegallo joegallo left a comment

Choose a reason for hiding this comment

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

🚢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/REST API REST infrastructure and utilities >enhancement Team:Core/Infra Meta label for core/infra team v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants