kz930 opened a new pull request, #7249:
URL: https://github.com/apache/texera/pull/7249

   ### What changes were proposed in this pull request?
   
   Four `attributeTypeRules` name keys that match no property, so the property 
editor's `findAttributeType` returns `undefined` and `checkConstraint` returns 
without checking anything.
   
   `LineConfig` used the Scala field names rather than the `@JsonProperty` 
names, and `ScatterMatrixChartOpDesc` named `value` where the property is 
`Selected Attributes`; both are retargeted at the property they meant. 
`Scatter3dChartOpDesc` and `FunnelPlotOpDesc` constrained a `title` that 
neither operator declares, and did so with the bare string `"string"` rather 
than an object, so even under a correct key `constraint.enum` / `const` / 
`allOf` would all be undefined and the check would still no-op; those two rules 
are removed rather than invented anew.
   
   ### Why are the changes needed?
   
   A line chart's x and y axes accept string columns today despite declaring 
`["integer", "long", "double"]`, and the same holds for the scatter matrix's 
dimensions. `BandConfig` extends `LineConfig` and inherited the same dead rule. 
Nothing reports a key that names no property, so the rules read as enforced 
while enforcing nothing.
   
   ### Does this PR introduce any user-facing change?
   
   Yes. Selecting a non-numeric column for a line chart's axes or the scatter 
matrix's Selected Attributes now shows the type warning the rule always 
intended. Nothing changes for a numeric column, and removing the two `title` 
rules changes nothing at all, since they never applied.
   
   ### How was this patch tested?
   
   `WorkflowOperator/compile`, `WorkflowOperator/scalafmtCheckAll`, and the 
four operators' existing descriptor specs (24 tests, all passing).
   
   Closes #7210
   
   Generated-by: Claude Code (Claude Opus 5)
   


-- 
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]

Reply via email to