jerryshao commented on code in PR #13250:
URL: https://github.com/apache/gravitino/pull/13250#discussion_r4059083262
##########
clients/client-java/src/main/java/org/apache/gravitino/client/GravitinoMetalake.java:
##########
@@ -1714,14 +1714,17 @@ public JobHandle runJob(String jobTemplateName,
Map<String, String> jobConf)
}
@Override
- public JobHandle getJob(String jobId) throws NoSuchJobException {
+ public JobHandle getJob(String jobId, boolean includeOutput) throws
NoSuchJobException {
Preconditions.checkArgument(StringUtils.isNotBlank(jobId), "job id must
not be null or empty");
+ Map<String, String> params =
+ includeOutput ? ImmutableMap.of("includeOutput", "true") :
Collections.emptyMap();
Review Comment:
Fair point, and accurate — leaving this one alone for now. This round was
scoped to the REST layer deliberately (the per-request override work already
meant touching `JobOperationDispatcher`, `JobManager`, and the two decorator
dispatchers just to plumb two `Integer` parameters); extending
`SupportsJobs#getJob` to carry them too would mean redoing the same
overload-compatibility work we did for `includeOutput` across both
`GravitinoMetalake`/`GravitinoClient` and the Python client, plus their tests.
I'll track this as a follow-up rather than fold it into this PR. Will leave
the docs as-is for now too, but agree it's worth a callout that these two
params are REST-only if we don't get to the client plumbing soon.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
