ozankabak commented on issue #8913: URL: https://github.com/apache/arrow-datafusion/issues/8913#issuecomment-1901253943
The main concern I have is composability. We have many use case where the flow goes something like this: 1. Visit/transform a given tree, and save per-node data during the process. 2. Make a decision based depending on the final result of the visitation. 3. Visit/transform the tree again, re-use the saved per-node data and only modify when necessary. (this can repeat multiple times) #8817 works towards having a composable architecture that lends itself to such flows, and will eliminate most major sources of code duplication concerning `TreeNode`. Similar to how `DynTreeNode` works, it introduces one generic object for `ExecutionPlan`-related trees, and one generic object for `PhysicalExpr`-related trees. Once we have such a reusable/composable "infrastructure", we can discuss/ideate on various flavors of the `transform` APIs and find a design that works well. -- 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]
