djanderson opened a new pull request, #6201: URL: https://github.com/apache/arrow-rs/pull/6201
# Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closes #123` indicates that this PR will close issue #123. --> Closes https://github.com/apache/arrow-rs/issues/6124. Supersedes https://github.com/apache/arrow-rs/pull/6137. # Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> This implements the handler for the new CommandStatementIngest message defined in [Arrow Flight SQL version 17.0](https://github.com/apache/arrow/blob/084387c56e45bf7e8335c28e14a2e61b16515ad5/format/FlightSql.proto). # What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> - exposes the new `CommandStatementIngest` and related message types (introduced in https://github.com/apache/arrow-rs/pull/6169) - adds a stub method, `do_put_statement_ingest`, to the `FlightSqlServer` trait - implements `execute_ingest` on the flight sql client - adds a simple integration test between sql client and test server # Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> Yes. The new method on the `FlightSqlServer` trait is a breaking API change. Also, I would like to draw reviewers' attention to the `execute_ingest` function on the client. There was more room for interpretation on the API there, and I referenced the C++ implementation of [ExecuteIngest](https://github.com/apache/arrow/commit/0d1ea5db1f9312412fe2cc28363e8c9deb2521ba#diff-24605705eb330ad4a29a7155687822cccc3efad5cef2d4abf913e157eabf391dR259) but preferred to stay consistent with the rust client's idioms where I could. For example, - I preferred to pass the `CommandStatementIngest` struct as a parameter, because other `pub` methods on the client "leak" the protobuf struct as a parameter (such as [get_tables](https://github.com/apache/arrow-rs/blob/master/arrow-flight/src/sql/client.rs#L295), where `CommandGetTables` is a similarly featureful protobuf struct) and it feels a bit more idiomatic for rust - I initially attempted to match the C++ API and use `RecordBatchReader` instead of just taking a `Vec<RecordBatch>`, but ran into problems with `&dyn RecordBatchReader` not being `Send` and all that jazz. The closest I could get working was `BoxStream<'static, RecordBatch>` but `Vec<RecordBatch>` felt like a cleaner API, especially for something intended for bulk ingest. Happy to take advice on either of the above or other points. <!--- If there are any breaking changes to public APIs, please add the `breaking change` label. --> -- 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]
