-
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
Change BroadcastResponse from ToXContentFragment to ToXContentObject #28878
Conversation
While working on elastic#27799, we find that it might make sense to change BroadcastResponse from ToXContentFragment to ToXContentObject, seeing that it's rather a complete XContent object and also the other Responses are normally ToXContentObject. By doing this, we can also move the XContent build logic of BroadcastResponse's subclasses, from Rest Layer to the concrete classes themselves.
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
1 similar comment
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
@@ -87,6 +86,7 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws | |||
if (recoveryStates == null || recoveryStates.size() == 0) { | |||
continue; | |||
} | |||
builder.startObject(); |
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.
Doesn't this result in an empty builder when !hasRecoveries()
? Shouldn't we be returning an empty object instead?
( Maybe it is ok, I don't what the convention is.. )
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.
@olcbean Yes, you are right. The builder.startObject();
builder.endObject();
pair should be put outside the condition I think. Just like what it was previously.
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.
thanks @PnPie I left a couple of comments but this looks good already!
@@ -197,7 +198,7 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws | |||
} | |||
builder.endObject(); | |||
} | |||
|
|||
builder.endObject(); | |||
return builder; |
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.
would you mind also changing the toString method here to call Strings.toString instead?
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.
Of course not :)
@@ -172,6 +174,7 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws | |||
builder.endObject(); | |||
} | |||
|
|||
builder.endObject(); |
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.
could you also make the two toXContent static methods private?
@@ -37,7 +36,7 @@ | |||
/** | |||
* Information regarding the recovery state of indices and their associated shards. | |||
*/ | |||
public class RecoveryResponse extends BroadcastResponse implements ToXContentFragment { | |||
public class RecoveryResponse extends BroadcastResponse { | |||
|
|||
private boolean detailed = false; |
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 just figured this flag is never read, we can rather remove it and simplify the rest action. We should also remove it from the request as it does nothing, and adjust the docs. The correct parameter is details
and not detailed
, but we don't accept it anymore since we introduced params validation a while ago. The flag doesn't need to be serialized either, as it only affects the xcontent output, is is simply a REST param passed through to the response like we do in other places. Would you like to open a follow-up PR to fix this?
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, cool ! of course :) I'll look at it after finishing these PRs, and it's like this it changes a little whlie working on Add Broadcast API 😄
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 opened #28910 to keep track of this.
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.
what do you think of removing the flag already from the response given that it does nothing? I think it would simplify the rest action
@@ -104,6 +104,8 @@ public void writeTo(StreamOutput out) throws IOException { | |||
|
|||
@Override | |||
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException { | |||
builder.startObject(); | |||
RestActions.buildBroadcastShardsHeader(builder, params, this); |
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.
given that in most cases we have the shards header, how about doing this in BroadcastResponse
:
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException {
builder.startObject();
RestActions.buildBroadcastShardsHeader(builder, params, this);
addCustomFields();
builder.endObject();
}
protected void addCustomFields() {
}
subclasses can override this additional method to add their own fields rather than repeating the shards header every time. There is always the possibility to also override toXContent for content where the shards header is not printed out.
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.
Exactly !
test this please |
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException { | ||
builder.startObject(); | ||
builder.field(VALID_FIELD, isValid()); | ||
RestActions.buildBroadcastShardsHeader(builder, params, this); |
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.
shall we leverage addCustomFields here too and just move the valid field after the shards header?
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 feel like we are putting the validate
field at the beginning on purpose https://www.elastic.co/guide/en/elasticsearch/reference/current/search-validate.html ? as it's for validation and we want to see the validate field at first ? If we modify the order here, will it impact elsewhere when it calls toXContent() of ValidateQueryResponse ?
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 see, but you can't rely on keys ordering when parsing json... we are free to change order as that is not guaranteed. Maybe we should then update the docs as well accordingly just to make sure that nobody thinks we guarantee that valid comes first.
retest this please |
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.
hi @PnPie sorry it took me a while to get back to this. I had one last look, ran the tests and found two small issues. Once those are addressed, I can merge this one in. I also took the liberty to merge upstream changes in and push corresponding commits to your repo to ease your work. Thanks!
return new BytesRestResponse(response.getStatus(), builder); | ||
} | ||
}); | ||
return channel -> client.admin().indices().refresh(refreshRequest, new RestToXContentListener<>(channel)); |
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.
we are losing the status code from refresh response here. You need to override getStatus
in RestToXContentListener
and take the status from the response.
@@ -147,15 +145,14 @@ public void writeTo(StreamOutput out) throws IOException { | |||
} | |||
|
|||
@Override | |||
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException { | |||
protected void addCustomXContentFields(XContentBuilder builder, Params params) throws IOException { |
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 makes IndicesStatsResponseTests#testInvalidLevel
fail. Could you please update the test so that it passes in a valid XContentBuilder
rather than null
?
Hello @javanna I update this, thanks for pushing the fix ! and also for another PR :) |
retest this plase |
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 @PnPie !
retest this please |
retest this please |
Conflicts resolved: server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestForceMergeAction.java
@javanna I merged master in. |
thanks a lot @PnPie ! |
…28878) While working on #27799, we find that it might make sense to change BroadcastResponse from ToXContentFragment to ToXContentObject, seeing that it's rather a complete XContent object and also the other Responses are normally ToXContentObject. By doing this, we can also move the XContent build logic of BroadcastResponse's subclasses, from Rest Layer to the concrete classes themselves. Relates to #3889
* es/master: (27 commits) [Docs] Add rank_eval size parameter k (#29218) [DOCS] Remove ignore_z_value parameter link Docs: Update docs/index_.asciidoc (#29172) Docs: Link C++ client lib elasticlient (#28949) [DOCS] Unregister repository instead of deleting it (#29206) Docs: HighLevelRestClient#multiSearch (#29144) Add Z value support to geo_shape Remove type casts in logging in server component (#28807) Change BroadcastResponse from ToXContentFragment to ToXContentObject (#28878) REST : Split `RestUpgradeAction` into two actions (#29124) Add error file docs to important settings Add note to low-level client docs for DNS caching (#29213) Harden periodically check to avoid endless flush loop (#29125) Remove deprecated options for query_string (#29203) REST high-level client: add force merge API (#28896) Remove license information from README.textile (#29198) Decouple more classes from XContentBuilder and make builder strict (#29197) [Docs] Fix missing closing block in cluster/misc.asciidoc RankEvalRequest should implement IndicesRequest (#29188) Use EnumMap in ClusterBlocks (#29112) ...
* es/6.x: (29 commits) [Docs] Add rank_eval size parameter k (#29218) Docs: Update docs/index_.asciidoc (#29172) Docs: Link C++ client lib elasticlient (#28949) Docs: HighLevelRestClient#multiSearch (#29144) [DOCS] Remove ignore_z_value parameter link Add Z value support to geo_shape Change BroadcastResponse from ToXContentFragment to ToXContentObject (#28878) REST : Split `RestUpgradeAction` into two actions (#29124) [DOCS] Unregister repository instead of deleting it (#29206) Remove type casts in logging in server component (#28807) Add error file docs to important settings Add note to low-level client docs for DNS caching (#29213) testShrinkAfterUpgrade should only set mapping.single_type if bwc version > 5.5.0 Harden periodically check to avoid endless flush loop (#29125) REST high-level client: add force merge API (#28896) Remove license information from README.textile (#29198) Decouple more classes from XContentBuilder and make builder strict (#29197) Propagate mapping.single_type setting on shrinked index (#29202) [Docs] Fix missing closing block in cluster/misc.asciidoc RankEvalRequest should implement IndicesRequest (#29188) ...
* master: (40 commits) Do not optimize append-only if seen normal op with higher seqno (elastic#28787) [test] packaging: gradle tasks for groovy tests (elastic#29046) Prune only gc deletes below local checkpoint (elastic#28790) remove testUnassignedShardAndEmptyNodesInRoutingTable elastic#28745: remove extra option in the composite rest tests Fold EngineDiskUtils into Store, for better lock semantics (elastic#29156) Add file permissions checks to precommit task Remove execute mode bit from source files Optimize the composite aggregation for match_all and range queries (elastic#28745) [Docs] Add rank_eval size parameter k (elastic#29218) [DOCS] Remove ignore_z_value parameter link Docs: Update docs/index_.asciidoc (elastic#29172) Docs: Link C++ client lib elasticlient (elastic#28949) [DOCS] Unregister repository instead of deleting it (elastic#29206) Docs: HighLevelRestClient#multiSearch (elastic#29144) Add Z value support to geo_shape Remove type casts in logging in server component (elastic#28807) Change BroadcastResponse from ToXContentFragment to ToXContentObject (elastic#28878) REST : Split `RestUpgradeAction` into two actions (elastic#29124) Add error file docs to important settings ...
While working on #27799, we find that it might make sense to change BroadcastResponse from ToXContentFragment to ToXContentObject, seeing that it's rather a complete XContent object and also the other Responses are normally ToXContentObject.
By doing this, we simplify the Response building in Rest layer by moving the implementation to corresponding response classes themselves, (maybe) where it should be.
Relates to #3889