kz930 opened a new pull request, #7946: URL: https://github.com/apache/texera/pull/7946
### What changes were proposed in this PR? The four advanced Sklearn trainers (SVC, SVR, KNN Classifier, KNN Regressor) take their hyperparameters as a table. Each row picks a parameter from a dropdown and supplies a value beside it. The parameter is a real dropdown backed by an enum, but the value was a bare text box carrying nothing: no accepted values, no format, no example, and no required marker. Typing `1` for `kernel`, or leaving the value empty, was accepted by the editor and only failed once the run reached scikit-learn. Each parameter's legal values are fixed, and the enum that fills the parameter dropdown already pairs every parameter with the Python callable that converts the user's text. The operator knew what it would accept and never said so. The enum now says it. Each parameter declares the values the estimator accepts where it takes a fixed set, and one value it accepts where it takes a range instead. Both come from scikit-learn rather than from judgement: the sets are read from `_parameter_constraints`, and the examples are each estimator's own signature default. A parameter with an accepted set carries no example, since the set already names every value worth offering. None of this can be annotated on `value`, because one field serves every parameter and the right constraint depends on which parameter the row chose. So the descriptor writes it into its own schema through a new one-method hook, resolving the parameter enum from the type argument that erasure leaves off the field. The rules sit under a Texera key of their own rather than as a JSON-Schema `allOf`, for the same reason `attributeTypeRules` does and whose grammar they borrow: the form builder merges the members of an `allOf` into a single field, which would leave one control carrying every parameter's constraints at once. The value was not required either. Which of the two inputs a row needs depends on `parametersSource`, which decides whether the row reads its value from the text box or from a column, so `HyperParameters` states that conditionally. ajv enforces it directly, and no frontend change was needed for that half. The form now gives the value the control its rules call for: a dropdown where the parameter is chosen from a set, a number input where it is read by `int()` or `float()`, and a plain text box where the rules say nothing. Three parameters get a constraint but no example: `gamma`, `metric` and `metric_params`. No value stated for them would survive the converter each declares, and those converters are the subject of their own issues. ### Any related issues, documentation, discussions? Closes #7936. Related but separate, both about converters this PR deliberately does not touch: #7593 covers `metric` and `metric_params`, whose declared converter is the wrong one, and #7945 covers `gamma`, which accepts both a word and a number and so needs a converter that can carry either. ### How was this PR tested? `SklearnAdvancedBaseDescSpec` gained five cases over the generated schema: an accepted set matching scikit-learn exactly, a numeric parameter read from its converter, a parameter constrained without an example, a rule present for every parameter whose converter says anything about it, and the conditional requirement of `value` against `attribute`. `formly-utils.spec.ts` gained sixteen over branch selection, the validator in both directions, and the message it produces. Every declared set, type and example was checked against scikit-learn 1.7.2 rather than assumed. The three word-valued sets (`kernel`, `weights`, `algorithm`) match their `StrOptions` exactly, with nothing missing and nothing extra, and all fourteen numeric examples are that estimator's own signature default and pass `_validate_params()`. Tested in the running application as well, on an SVM Classifier Trainer: picking `kernel` renders the value as a dropdown of the five kernels, switching the row to `C` turns it into a number input, and a row with no parameter chosen is marked invalid before the workflow can run. ### Was this PR authored or co-authored using generative AI tooling? 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]
