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

Compatible logic for include_type_param and RestCreateIndexAction #54197

Merged

Conversation

pgomulka
Copy link
Contributor

@pgomulka pgomulka commented Mar 25, 2020

Refactoring of the compatible infrastructure to allow registering multiple RestAction under the same path. It only extends the current mechanism which allowed registering RestAction under the same path but with different method. Now it also uses a version together with a method to find a matching RestAction

This PR also provides a V7 compatible RestCreateIndexAction that needs include_Type_param and a different logic for parsing mapping from its body.

fixed get/index tests
CompatRestIT. test {yaml=get/21_stored_fields_with_types/Stored fields}
CompatRestIT. test {yaml=get/71_source_filtering_with_types/Source
filtering}

CompatRestIT. test {yaml=index/70_mix_typeless_typeful/Index call that
introduces new field mappings}
CompatRestIT. test {yaml=index/70_mix_typeless_typeful/Index with
typeless API on an index that has types}

however the last one from get is still failing
CompatRestIT. test {yaml=get/100_mix_typeless_typeful/GET with typeless
API on an index that has

relates #54160

fixed get/index tests
CompatRestIT. test {yaml=get/21_stored_fields_with_types/Stored fields}
CompatRestIT. test {yaml=get/71_source_filtering_with_types/Source
filtering}

CompatRestIT. test {yaml=index/70_mix_typeless_typeful/Index call that
introduces new field mappings}
CompatRestIT. test {yaml=index/70_mix_typeless_typeful/Index with
typeless API on an index that has types}

however the last one from get is still failing
CompatRestIT. test {yaml=get/100_mix_typeless_typeful/GET with typeless
API on an index that has
@pgomulka pgomulka added the WIP label Mar 25, 2020
@pgomulka pgomulka self-assigned this Mar 25, 2020
@cla-checker-service
Copy link

cla-checker-service bot commented Mar 27, 2020

💚 CLA has been signed

@pgomulka pgomulka added the :Core/Infra/Core Core issues without another label label Mar 27, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (:Core/Infra/Core)

@pgomulka pgomulka added :Core/Infra/REST API REST infrastructure and utilities and removed :Core/Infra/Core Core issues without another label WIP labels Mar 27, 2020
@pgomulka pgomulka changed the title WIP compatible logic for include_type_param Compatible logic for include_type_param and RestCreateIndexAction Mar 27, 2020
@pgomulka pgomulka marked this pull request as ready for review March 27, 2020 14:28
}
if (handler == null) {
if (handleNoHandlerFound(rawPath, requestMethod, uri, channel)) {
return;
}
} else {
if(handler.compatibilityRequired() == false //regular (not removed) handlers are always dispatched
Copy link
Contributor Author

Choose a reason for hiding this comment

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

no longer need that logic. each handler is registered with a compatibleWith version.
The compatible API registers with Version.7
the current version register with Version.Current
this version is being used in handlers.getHandler to get the right handler

@pgomulka pgomulka mentioned this pull request Mar 30, 2020
66 tasks
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.

looking good, I like the approach here. some nitpicks, a request for a bit more testing, and a request to pass around a real Version object.

this.path = path;
this.methodHandlers = new HashMap<>(methods.length);
for (RestRequest.Method method : methods) {
methodHandlers.put(method, handler);
methodHandlers.putIfAbsent(method, new HashMap<>());
methodHandlers.get(method).put(version, handler);
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: this can be simplified to methodHandlers.computeIfAbsent(method, k -> new HashMap<>()).put(version, handler); (mostly a cosmetic change though...)

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

@pgomulka
Copy link
Contributor Author

ok to test

@pgomulka
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/bwc

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, thanks for the revisions.

@pgomulka
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/bwc

1 similar comment
@pgomulka
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/bwc

Copy link
Member

@jaymode jaymode left a comment

Choose a reason for hiding this comment

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

Thank you for bearing with me on the slow turnaround for a review. I like this. I left some nits and suggestions. One change in MethodHandlers I think we do need to make though.

@@ -55,7 +53,7 @@ public String getName() {

@Override
public List<Route> routes() {
assert Version.CURRENT.major == 8 : "REST API compatilbity for version 7 is only supported on version 8";
assert Version.CURRENT.major == 8 : "REST API compatibility for version 7 is only supported on version 8";
Copy link
Member

Choose a reason for hiding this comment

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

This is a different way of doing things, but I'd much rather keep the assertion out of the individual rest handlers and add logic to the RestController for throwing an exception if a handler is registered with an incompatible version. So when the version is bumped to 9 that we would throw for any handler registered with a compatible version of 7. What do you think?

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 idea, this will reduce duplication too

*
* Handlers can be registered under the same path and method, but will require to have different versions (CURRENT or CURRENT-1)
*
* //todo What if a handler was added in V8 but was not present in V7?
Copy link
Member

Choose a reason for hiding this comment

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

IMO if you request V7 compatibility mode but the API doesn't exist in V7 then this should be a bad request (HTTP 400)

if(versionToHandlers == null){
return null;
}
if (versionToHandlers.containsKey(version)) {
Copy link
Member

Choose a reason for hiding this comment

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

Is it ever valid for an entry in the map to have a null handler? I would think not so this could be simplified to:

final RestHandler handler = versionToHandlers.get(version);
return handler != null || version.equals(Version.CURRENT) ? handler : versionToHandlers.get(Version.CURRENT);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agree - I don't expect null values in versionToHandlers map. Will apply the suggestion

Comment on lines 77 to 78
private final long requestId;
private final Version compatibleApiVersion;
Copy link
Member

Choose a reason for hiding this comment

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

This is a nit but I prefer to keep final variables grouped together and non-final member variables grouped together. This means that these two variables should be moved under httpChannel and followed by an empty line, which would separate them from httpRequest and contentConsumed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agree, I like that arrangement too

@pgomulka pgomulka requested a review from jaymode April 27, 2020 13:06
Copy link
Member

@jaymode jaymode left a comment

Choose a reason for hiding this comment

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

LGTM!

@pgomulka pgomulka merged commit 3a8303e into elastic:compat_rest_api Apr 28, 2020
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants