Clarify some ToXContent implementations behaviour #41000
Conversation
This change adds either ToXContentObject or ToXContentFragment to classes directly implementing ToXContent currently. This helps in reasoning about whether those implementations output full xcontent object or just fragments. Relates to elastic#16347
|
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
thanks @cbuescher for picking this up. I left a couple of comments, especially on making requests and response implement ToXContentObject, if that makes sense.
...c/main/java/org/elasticsearch/action/admin/indices/template/put/PutIndexTemplateRequest.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/action/support/DefaultShardOperationFailedException.java
Show resolved
Hide resolved
| @@ -150,7 +152,7 @@ public boolean higherThan(Type other) { | |||
| /** | |||
| * Simple class representing a single decision | |||
| */ | |||
| public static class Single extends Decision { | |||
| public static class Single extends Decision implements ToXContentObject { | |||
There was a problem hiding this comment.
These two are confusing me. Given that the Decision is included in other objects, and it can either be an object or a fragment, I am not following how it can work, given that where we include them we simply call toXContent against them. Am I wrong thinking that only one of the two implementations can work and the other one may break the json?
There was a problem hiding this comment.
To me it looks like the Single decisions are self-contained json, whereas the Multi decision is composed of several single decisions and just prints those in consecutive order. This seems to work because we alway seem to wrap them in an array (e.g. in MoveDecision#toXContent, NodeAllocationResult#toXContent). I think this is why the parent Decision is solely implementing ToXContent because the only thing guaranteed is that you can somehow deserialize it. The object hierarchy might be a bit off here but I think its out of scope for this PR to fix this.
...c/main/java/org/elasticsearch/xpack/core/watcher/transport/actions/get/GetWatchResponse.java
Outdated
Show resolved
Hide resolved
...lugin/core/src/main/java/org/elasticsearch/xpack/core/rollup/action/StopRollupJobAction.java
Outdated
Show resolved
Hide resolved
...ugin/core/src/main/java/org/elasticsearch/xpack/core/rollup/action/StartRollupJobAction.java
Outdated
Show resolved
Hide resolved
...lugin/core/src/main/java/org/elasticsearch/xpack/core/rollup/action/GetRollupJobsAction.java
Outdated
Show resolved
Hide resolved
|
@elasticmachine run elasticsearch-ci/packaging-sample |
|
@javanna thanks for the review, I hope I adressed most of your concerns, left a reply about your question about the "Decision" objects. I'm not exactly sure how to proceed here or if we should just leave it as-is for the moment. In any case, I think this is ready for another look. |
This change adds either ToXContentObject or ToXContentFragment to classes directly implementing ToXContent currently. This helps in reasoning about whether those implementations output full xcontent object or just fragments. Relates to #16347
|
@javanna thanks for the review |
This change adds either ToXContentObject or ToXContentFragment to classes directly implementing ToXContent currently. This helps in reasoning about whether those implementations output full xcontent object or just fragments. Relates to elastic#16347
This change adds either ToXContentObject or ToXContentFragment to classes
directly implementing ToXContent currently. This helps in reasoning about
whether those implementations output full xcontent object or just fragments.
Relates to #16347