DanielLeens commented on issue #10942: URL: https://github.com/apache/seatunnel/issues/10942#issuecomment-4530993266
Thanks for writing this up so concretely. I agree this is worth discussing as a design topic, not just as another transform-local fix. The underlying problem is real. In the current execution path, `SeaTunnelTransformCollector` forwards the same `Record<?>` reference to sibling outputs, and we still have transform implementations that mutate the input `SeaTunnelRow` in place. `ReplaceTransform` was fixed by #10941, but `TableMergeTransform` and `RowKindExtractorTransform` are good examples showing the broader contract gap. That said, I would be careful with the current `SeaTunnelRowAccessor` proposal as-is. Today `SeaTunnelRowAccessor` still exposes `getFields()`, which returns the underlying mutable `Object[]`, so it is not yet a hard read-only boundary. Also, the common transform stack is still built around `AbstractSeaTunnelTransform.transformRow(SeaTunnelRow)`, and even identity transforms currently rely on passing the original row through without copying. So this is broader than one small signature cleanup. A practical next step would be: 1. close the remaining known in-place mutators and add regression tests for sibling fan-out contamination 2. define exactly what "read-only row" means, especially around `getFields()` and zero-copy pass-through cases 3. then evaluate an incremental migration path, for example a new accessor-based hook plus deprecation, instead of a sudden signature flip So overall, I think the problem statement is valid and the direction is promising, but the accessor contract and migration boundary need to be made more explicit before the community can confidently choose the next step. -- 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]
