github-actions[bot] commented on code in PR #69749:
URL: https://github.com/apache/doris/pull/69749#discussion_r4401555635
##########
fe/fe-core/src/main/java/org/apache/doris/load/routineload/RoutineLoadJob.java:
##########
@@ -438,6 +439,13 @@ protected void setOptional(CreateRoutineLoadInfo info)
throws UserException {
if (!StringUtils.isEmpty(info.getWorkloadGroupName())) {
jobProperties.put(WORKLOAD_GROUP, info.getWorkloadGroupName());
}
+
+ // Only write the key when the user declared it. An absent key means
"not declared" and
+ // keeps the existing implicit resolution, which is also what later
versions rely on to
+ // tell a pinned group apart from an inherited one.
+ if (!StringUtils.isEmpty(info.getComputeGroupName())) {
+ jobProperties.put(COMPUTE_GROUP, info.getComputeGroupName());
Review Comment:
[P2] Preserve the declared group in SHOW CREATE ROUTINE LOAD
The new binding is stored here, but `getShowCreateInfo()` emits a fixed
property list that never includes `compute_group`. `SHOW CREATE ROUTINE LOAD`
calls that method, so creating or ALTERing a job to `cg_b`, exporting its DDL,
and recreating it from a session on `cg_a` silently creates an unpinned job
running in A. Emit the current `getDeclaredComputeGroup()` in that SQL when
nonempty, preserving the absent-key behavior for jobs without a declaration,
and cover the round trip after ALTER.
##########
fe/fe-core/src/main/java/org/apache/doris/job/extensions/mtmv/MTMVTask.java:
##########
@@ -1680,6 +1684,34 @@ private void setupComputeGroup(ConnectContext ctx) {
}
}
+ private void applyComputeGroup(ConnectContext ctx) {
Review Comment:
[P2] Apply the MV binding to incremental dry-run contexts
Keeping this initialization private to `MTMVTask` misses
`RefreshMTMVCommand.dryRunRefresh()`, which creates an internal context through
`MTMVPlanUtil.createMTMVContext()` and executes the delta query directly. That
initializer copies `workload_group` but never the new `compute_group`. For an
IVM MV pinned to B with a workload group existing only in B, while admin
defaults to A, a nonempty `REFRESH MATERIALIZED VIEW mv INCREMENTAL WITH DRY
RUN` looks up that workload group in A and fails although real refresh succeeds
in B. Apply the declaration in shared MV context initialization or explicitly
cover this foreground execution path too.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
