GitHub user kz930 added a comment to the discussion: Scaling verification of workflow to Python translation — looking for input
Two updates: how one operator is verified end to end, and the configuration rules, which have settled since the posts above. <img width="4032" height="2252" alt="IMG_7434" src="https://github.com/user-attachments/assets/bfa23e81-744d-4181-a047-06345f371f78"; /> One operator descriptor — one configuration, one input — is run two ways and the two outputs are compared. On the native path a plain JVM operator runs in process, while an operator that is itself a Python operator has its `generatePythonCode()` output run in a Python worker, because that is what the platform does for it. On the other path `generateStandaloneCode()` produces the exported script and it runs on the same input. Both write JSONL, and a comparator decides pass or fail. The three Python-facing steps draw from long-lived worker pools rather than starting an interpreter per check (see #6975). **Comparison.** Rows compare as a table, ignoring order — parallel execution order is not something the platform promises, so requiring it would report differences that are not translation bugs. The exception is the sort family, where order is the point of the operator: Sort, Stable Merge Sort and Sort Partitions declare `orderSensitive` and compare line by line. **Configuration.** Nobody hand-writes one per operator; every value below comes from what the operator already declares. *Columns.* A single-column field takes the column its `@SampleColumn` names, else the first column not already claimed by a sibling field whose type it accepts — without that preference a scatter plot's x and y both land on the first numeric column and the test is a degenerate diagonal. A multi-column field takes every column whose type fits. Optional columns stay unset in the base configuration, which is what real workflows carry, and are filled in one extra run so the branch for a column that *is* set gets compared too; an optional list takes a single column there, since thirty group-by keys would make every row its own group. *Dropdowns and checkboxes.* Every dropdown value and both checkbox values are run, one field at a time rather than in combination, on the configuration with optionals left unset. *Numbers.* A declared default is used as it stands. Otherwise: the midpoint of a declared range, so an opacity of 0.0–1.0 becomes 0.5; with only a lower bound, twice it or half the row count, whichever is larger, because a field declaring "at least 30" usually defaults to 30 and filling the bound would just re-run the base configuration; with no bound, half the row count, which puts a Limit inside the fixture rather than past its end. Where a row holds a pair that must differ to mean anything — a step's start and end — the second steps one past the first, so ten rows give 5 and 6. *Strings.* Two values per field. The first is what the field declares — its default, or the first entry of its `examples` list, which lets a field say it wants a URL or a delimiter without inventing a constraint to hang that on — and `1` when it declares neither, a value the shared fixture contains so filters match rows instead of nothing. The second is `a"b`: legal to type anywhere, and it ends a Python string literal, so a generator splicing it unescaped emits a script that does not parse. Several free-text fields in one operator take `a"b`, `a"b2`, `a"b3` in the same run — still hostile but distinct, because where the field names an output column one shared value asks for two columns of the same name and the configuration is rejected before anything runs. Constrained fields are excluded (a column picker, a dropdown, a number in a string box, a pattern that rejects the quote): there the value would be refused rather than spliced, so no escaping question arises. Successive row s holding an unconstrained string read `1`, `2`, `3`. That last check has been the most productive single rule so far — it found unescaped splicing across a large share of the standalone generators, none of which any well-behaved test value would reach. GitHub link: https://github.com/apache/texera/discussions/6072#discussioncomment-17885502 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
