github-actions[bot] commented on code in PR #69340:
URL: https://github.com/apache/doris/pull/69340#discussion_r4332554719
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/rewrite/AccessPathExpressionCollector.java:
##########
@@ -576,11 +576,54 @@ public Void visitArrayMap(ArrayMap arrayMap,
CollectorContext context) {
Expression argument = arrayMap.getArgument(0);
if ((argument instanceof Lambda)) {
- return collectArrayPathInLambda((Lambda) argument, context);
+ Lambda lambda = (Lambda) argument;
+ return collectArrayMapPathInLambda(lambda, context);
}
return visit(arrayMap, context);
}
+ private Void collectArrayMapPathInLambda(Lambda lambda, CollectorContext
context) {
+ if (isRootContainerMetadata(context)) {
+ // A metadata requirement on the ARRAY_MAP result itself (OFFSET
for cardinality(arr),
+ // NULL for arr IS NULL) describes the output ARRAY container, not
the lambda elements.
+ // The output container is shaped by the input arrays: array_map
copies the first
+ // input's offsets and its null map is the union of all inputs'
null maps. Pushing that
+ // context into the lambda body would attach the metadata to the
element layer instead,
+ // producing e.g. `arr.*.OFFSET`, which the BE rejects for a
struct element (OFFSET
+ // metadata is only supported at array/map/string level). Route
the container metadata
+ // to the input arrays, and collect the element paths the lambda
actually reads with a
+ // fresh data context so that the elements stay available to the
lambda body.
+ for (ArrayItemReference lambdaArgument :
lambda.getLambdaArguments()) {
+ continueCollectAccessPath(lambdaArgument.getArrayExpression(),
copyContext(context));
Review Comment:
[P1] Normalize metadata for map-produced input arrays
This loop also forwards OFFSET through computed array inputs. With nested
pruning enabled, a valid plan is:
```text
Project(cardinality(array_map(x -> x.v + 1, map_values(m))))
Scan(m: MAP<STRING, STRUCT<v: INT>>)
```
`visitMapValues` prefixes `VALUES` onto the new root META `[OFFSET]`
request, producing `m.VALUES.OFFSET` alongside the lambda's DATA `m.VALUES.v`.
`NestedColumnPruning` retains both paths, and the BE map reader routes the
former to its struct value reader, which rejects OFFSET metadata with E-3110
before the DATA path can override it. Before this change, the arithmetic lambda
body reset the metadata context and collected only the valid `m.VALUES.v` path.
This is a root-container request on a `map_values` input, so the
descendant-path guard added for the existing thread does not cover it.
Normalize container metadata through these array producers (as
`visitCardinality` already does for `MapKeys`/`MapValues`), or fall back to
collecting their data, and add a regression for this input shape.
--
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]
