lidavidm commented on issue #811: URL: https://github.com/apache/arrow-adbc/issues/811#issuecomment-2123685066
> I think this would be a bit of a pain to manage. Why not add `rows_affected` to the `on_schema` call? +1 > What if the receiver e.g. can't allocate memory for an async task? I don't see how you get out of having to check the error in two locations in general, and it feels nicer for things like parameter validation failures to fail immediately. Hmm. For instance, in Rust, is it typical to have `Result<Future<T>>`, or just `Future<T>`? re: > Could theoretically be part of the Arrow C Stream for ABI stability (e.g., I could make an interface for an IPC writer from this and wire it up directly to an ADBC call from another Python package) Maybe we could add a `void*` argument for extensions? e.g. `on_schema` could have an argument that can be cast to an ADBC type containing the row count. Or we could do what we're already doing, and have ADBC expose top-level getters that take in this case an `AsyncArrowStream` and return ADBC-specific information (error details, row count, etc) -- 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]
