Refactored TransportSingleCustomOperationAction, subclasses and requests #7214
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… and requests TransportSingleCustomOperationAction is subclassed by two similar, yet different transport action: TransportAnalyzeAction and TransportGetFieldMappingsAction. Made their difference and similarities more explicit by sharing common code and moving specific code to subclasses: - moved index field to the parent SingleCustomOperationAction class - moved the common check blocks code to the parent transport action class - moved the main transport handler to the TransportAnalyzeAction subclass as it is only used to receive external requests through clients. In the case of the TransportGetFieldMappingsIndexAction instead, the action is internal and executed only locally as part of the user facing TransportGetFieldMappingsAction. The corresponding request gets sent over the transport though as part of the related shard request - removed the get field mappings index action from the action names mapping as it is not a transport handler anymore. It was before although never used.
| @@ -83,12 +111,18 @@ public void beforeLocalFork() { | |||
| public void readFrom(StreamInput in) throws IOException { | |||
| super.readFrom(in); | |||
| preferLocal = in.readBoolean(); | |||
| if (in.getVersion().onOrAfter(Version.V_1_4_0)) { | |||
| index = in.readOptionalString(); | |||
| } | |||
There was a problem hiding this comment.
Since the index on not optional for the get field mappings action, maybe there should rather be 2 overridable protected methods readIndex and writeIndex? This way we wouldn't even need the version checks?
There was a problem hiding this comment.
makes sense, the reason why I didn't do it is that on the long run bw comp checks will go away and everything would be simpler if the index is serialized by the class that holds it. On the other hand the additional methods you suggest don't complicate things that much.
|
Updated according to review's comment |
|
LGTM |
javanna
added a commit
that referenced
this pull request
Aug 11, 2014
… and requests TransportSingleCustomOperationAction is subclassed by two similar, yet different transport action: TransportAnalyzeAction and TransportGetFieldMappingsAction. Made their difference and similarities more explicit by sharing common code and moving specific code to subclasses: - moved index field to the parent SingleCustomOperationAction class - moved the common check blocks code to the parent transport action class - moved the main transport handler to the TransportAnalyzeAction subclass as it is only used to receive external requests through clients. In the case of the TransportGetFieldMappingsIndexAction instead, the action is internal and executed only locally as part of the user facing TransportGetFieldMappingsAction. The corresponding request gets sent over the transport though as part of the related shard request - removed the get field mappings index action from the action names mapping as it is not a transport handler anymore. It was before although never used. Closes #7214
javanna
added a commit
that referenced
this pull request
Sep 8, 2014
… and requests TransportSingleCustomOperationAction is subclassed by two similar, yet different transport action: TransportAnalyzeAction and TransportGetFieldMappingsAction. Made their difference and similarities more explicit by sharing common code and moving specific code to subclasses: - moved index field to the parent SingleCustomOperationAction class - moved the common check blocks code to the parent transport action class - moved the main transport handler to the TransportAnalyzeAction subclass as it is only used to receive external requests through clients. In the case of the TransportGetFieldMappingsIndexAction instead, the action is internal and executed only locally as part of the user facing TransportGetFieldMappingsAction. The corresponding request gets sent over the transport though as part of the related shard request - removed the get field mappings index action from the action names mapping as it is not a transport handler anymore. It was before although never used. Closes #7214
clintongormley
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TransportSingleCustomOperationActionis subclassed by two similar, yet different transport actions:TransportAnalyzeActionandTransportGetFieldMappingsIndexAction. Made their difference and similarities more explicit by sharing common code and moving specific code to subclasses:SingleCustomOperationActionclassTransportAnalyzeActionsubclass as it is only used to receive external requests through clients. In the case of theTransportGetFieldMappingsIndexActioninstead, the action is internal and executed only locally as part of the user facingTransportGetFieldMappingsAction. The corresponding request gets sent over the transport though as part of the related shard request