nzw921rx commented on PR #12804:
URL: https://github.com/apache/seatunnel/pull/12804#issuecomment-6197306704
Thanks for the thorough review, @DanielLeens! All five items are addressed
on the current head
(`ff53748`).
**Issue 1 - DataValidator global policy.**
`DataValidatorMultiCatalogTransform` now overlays
`row_error_handle_way` / `row_error_handle_way.error_table` onto the config
of every
`table_transform` entry (an entry that declares its own value keeps it).
Covered by
`DataValidatorTransformFactoryTest#testGlobalRouteToTablePolicyReachesTableTransformEntries`
(the
error table is produced and the invalid row gets `table_id = db.error_data`
at runtime) and by the
new E2E `data_validator_route_to_table_with_table_transform.conf`, where
both the transform-level
table and the entry-selected table route their invalid row into the shared
error table.
**Issue 2 - FilterRowKind.** Reverted: the transform fails closed again
(`SeaTunnelRuntimeException`
when neither list is configured) and the removed guard test
`testDirectConstructionWithEmptyKindsFailsOnTransform` is restored.
**Issue 3 - incompatible changes.** Added an entry to
`docs/{en,zh}/introduction/concepts/incompatible-changes.md` with the two
new error messages and the
migration (add `table_path`, complete the entry); the checklist item is
ticked.
**Issue 4 - docs.** `docs/{en,zh}/transforms/transform-multi-table.md` now
documents that an entry
has to select its table with a non-blank `table_path`, that each entry is
validated as a complete
single-table rule, and the resolution order (entry > `table_match_regex`
rule > unchanged). The full
rewrite of the 18 per-plugin documents is tracked in #12809 instead of this
PR.
**Issue 5 - Assert unit test.**
`AssertRuleParserTest#testParseCatalogTableRuleSinkType` covers
declared and matching, declared and mismatching, and omitted (`sink_type ==
null` skips the
comparison).
**3.2 maintainability suggestion.** Implemented: every affected transform
now has a
`testTransformLevelRuleDetectionMatchesTheTableRule` test (backed by the new
`TransformLevelRuleAssertions`), which verifies that the
`hasTransformLevelRuleConfigured` override
detects exactly the mandatory options of the factory `tableRule` and none of
the other declared
options. I checked that it fails with a descriptive message when an override
drifts.
Verification on the current head: `seatunnel-transforms-v2` UT 1369/1369
green, `connector-assert`
UT green, and locally against the Zeta container `TestDataValidatorIT` 9/9
and `TestFilterRowKindIT`
3/3. The PR description has been updated accordingly.
--
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]
