DanielLeens commented on issue #10942: URL: https://github.com/apache/seatunnel/issues/10942#issuecomment-4538940437
Thanks for raising the `DataValidatorTransform` example. I think it highlights an important distinction in this discussion. A read-only transform input contract does not have to mean "copy the row for every transform." For transforms like `DataValidatorTransform` that only inspect the input, an accessor-style read-only view can still stay zero-copy. The copy cost only becomes unavoidable if we choose the other direction: defensive copying in `SeaTunnelTransformCollector` on fan-out. So from my perspective there are really two separate design questions here: 1. what is the narrowest correctness fix for sibling-branch contamination 2. what should the long-term transform input contract be A collector-side copy on fan-out is attractive as a minimal safety fix because it can close the shared-reference bug without changing every transform API. But it only solves the sibling contamination part, and it still leaves the general transform contract mutable. The accessor direction is stronger semantically, but then the proposal needs to make two things much more explicit: 1. what counts as truly read-only, since the current `SeaTunnelRowAccessor` still exposes mutable internals like `getFields()` 2. how identity / pass-through transforms should behave without turning every path into an eager copy So I would suggest updating the proposal to compare those two directions directly: surface area, compatibility impact, runtime cost, and what class of bugs each one prevents. That will make the community trade-off much easier to evaluate. -- 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]
