-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Compatible logic for include_type_param and RestCreateIndexAction #54197
Conversation
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
💚 CLA has been signed |
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
} | ||
if (handler == null) { | ||
if (handleNoHandlerFound(rawPath, requestMethod, uri, channel)) { | ||
return; | ||
} | ||
} else { | ||
if(handler.compatibilityRequired() == false //regular (not removed) handlers are always dispatched |
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.
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
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.
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.
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Show resolved
Hide resolved
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Show resolved
Hide resolved
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Outdated
Show resolved
Hide resolved
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Outdated
Show resolved
Hide resolved
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/action/ActionModule.java
Outdated
Show resolved
Hide resolved
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); |
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: this can be simplified to methodHandlers.computeIfAbsent(method, k -> new HashMap<>()).put(version, handler);
(mostly a cosmetic change though...)
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 idea!
server/src/main/java/org/elasticsearch/rest/MethodHandlers.java
Outdated
Show resolved
Hide resolved
ok to test |
@elasticmachine run elasticsearch-ci/bwc |
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, thanks for the revisions.
@elasticmachine run elasticsearch-ci/bwc |
1 similar comment
@elasticmachine run elasticsearch-ci/bwc |
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.
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.
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Outdated
Show resolved
Hide resolved
...patibility/src/main/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7.java
Outdated
Show resolved
Hide resolved
@@ -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"; |
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 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?
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 idea, this will reduce duplication too
...ility/src/test/java/org/elasticsearch/rest/compat/version7/RestCreateIndexActionV7Tests.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/rest/MethodHandlers.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/rest/MethodHandlers.java
Outdated
Show resolved
Hide resolved
* | ||
* 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? |
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.
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)) { |
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.
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);
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.
agree - I don't expect null values in versionToHandlers
map. Will apply the suggestion
private final long requestId; | ||
private final Version compatibleApiVersion; |
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 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
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.
agree, I like that arrangement too
Co-Authored-By: Jay Modi <[email protected]>
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!
server/src/main/java/org/elasticsearch/rest/RestController.java
Outdated
Show resolved
Hide resolved
Co-Authored-By: Jay Modi <[email protected]>
…a/elasticsearch into compat/create_index_include_type
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