DanielLeens commented on issue #11061: URL: https://github.com/apache/seatunnel/issues/11061#issuecomment-4688435485
Thanks for adding the architecture note, and I also saw PR #11062. The direction is reasonable, but the first reviewable delivery needs a very explicit semantic boundary. Today the transform runtime is still row-driven `flatMap`, so the safest V1 contract is: 1. row-scoped expression evaluation 2. JSON extraction / projection 3. UNNEST-style expansion from a single input row 4. schema inference within that row-scoped model What I would avoid for the first increment is presenting this as general \"full SQL capability\" in a way that implies real cross-row `GROUP BY`, window, or multi-input JOIN semantics. In the current execution model, those would either be unsupported or only syntactically accepted without the semantics users normally expect from a relational engine. If PR #11062 keeps the first slice honest about that boundary, it becomes much easier to review and much easier for users to understand. -- 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]
