You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Weston Pace / @westonpace:
This seems like it will be tricky. The fetch node is a sink node. The consumer currently expects sink nodes to come from the caller. I'm not sure of a great way to work around this.
Brainstorming on a currently meeting-fried brain I might think something like...
The FromProto for relation returns a current ordering and fetch info
Note, if FromProto is called and there is already an ordering / fetch info then it should be an error as Acero can't handle this
The ordering / fetch info is passed on to the declaration factory in addition to the other two inputs
The declaration factories (at least the consuming sink one) is extended so that, if an ordering / fetch info is present, then it uses the appropriate sink node.
Maybe ordering / fetch info could be part of declaration info? CC @bkietz
Apache Arrow JIRA Bot:
This issue was last updated over 90 days ago, which may be an indication it is no longer being actively worked. To better reflect the current state, the issue is being unassigned per project policy. Please feel free to re-take assignment of the issue if it is being actively worked, or if you plan to start that work soon.
This does not support the clustered sort direction, custom sort functions, or complex (non-reference) expressions as sort keys.
* Closes: #32763
Authored-by: Weston Pace <[email protected]>
Signed-off-by: Antoine Pitrou <[email protected]>
Serializing FetchNode with Substrait.
Reporter: Vibhatha Lakmal Abeykoon / @vibhatha
Note: This issue was originally created as ARROW-17503. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: