This is an automated email from the ASF dual-hosted git repository. github-merge-queue[bot] pushed a commit to branch gh-readonly-queue/main/pr-7344-f46b2a71d4bc7d96cc2987a34e608717f239f39d in repository https://gitbox.apache.org/repos/asf/texera.git
commit 6cfd7244a7fc804e73dba9386751399e4a3fb0fd Author: Kary Zheng <[email protected]> AuthorDate: Wed Aug 5 16:38:01 2026 -0700 feat(visualization): declare the column type Sankey Diagram's value requires (#7344) ### What changes were proposed in this PR? Sankey Diagram's value column is grouped by source and target and summed into the width of each link, so it accepts only a number, but it declared no `attributeTypeRules` and the form therefore offered every column. It now declares `integer`, `long` or `double`, the way Range Slider's y-axis and Radar Chart's value columns already do. Source and target stay unconstrained: they are node labels, and any type reads as one. ### Any related issues, documentation, discussions? Closes #7319. Same class as #7341, for a different operator. ### How was this PR tested? `SankeyDiagramOpDescSpec` passes. The behaviour the rule prevents was reproduced first: with a string value column the group-and-sum concatenates rather than adds, so a three-row frame reaches plotly as `link.value = ('ab', 'c')`, and plotly accepts non-numeric link values without raising — the diagram renders with widths that mean nothing, and no error is reported anywhere. The rule key was checked against the property it names, since a key matching no property is silently inert (#7210); `Value Attribute` carries a space, which the property editor handles the same way it already handles Range Slider's `Y-axis`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) Co-authored-by: Claude Opus 5 (1M context) <[email protected]> --- .../visualization/sankeyDiagram/SankeyDiagramOpDesc.scala | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/visualization/sankeyDiagram/SankeyDiagramOpDesc.scala b/common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/visualization/sankeyDiagram/SankeyDiagramOpDesc.scala index b686f124af..7e6689bd72 100644 --- a/common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/visualization/sankeyDiagram/SankeyDiagramOpDesc.scala +++ b/common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/visualization/sankeyDiagram/SankeyDiagramOpDesc.scala @@ -20,7 +20,7 @@ package org.apache.texera.amber.operator.visualization.sankeyDiagram import com.fasterxml.jackson.annotation.{JsonProperty, JsonPropertyDescription} -import com.kjetland.jackson.jsonSchema.annotations.JsonSchemaTitle +import com.kjetland.jackson.jsonSchema.annotations.{JsonSchemaInject, JsonSchemaTitle} import org.apache.texera.amber.core.tuple.{AttributeType, Schema} import org.apache.texera.amber.pybuilder.PythonTemplateBuilder.PythonTemplateBuilderStringContext import org.apache.texera.amber.pybuilder.PyStringTypes.EncodableString @@ -32,6 +32,17 @@ import org.apache.texera.amber.pybuilder.PythonTemplateBuilder import javax.validation.constraints.NotNull +// The value column is summed per source/target pair and becomes the width of +// the link, so it has to be a number: strings concatenate instead of adding and +// plotly accepts the result without complaint. Source and target are node +// labels and take any type. +@JsonSchemaInject(json = """ +{ + "attributeTypeRules": { + "Value Attribute": { "enum": ["integer", "long", "double"] } + } +} +""") class SankeyDiagramOpDesc extends PythonOperatorDescriptor { @JsonProperty(value = "Source Attribute", required = true)
