-
Notifications
You must be signed in to change notification settings - Fork 803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement FlightSQL spec change to support stateless prepared statements #5433
Implement FlightSQL spec change to support stateless prepared statements #5433
Conversation
Marking as draft as my understanding of the status of apache/arrow#37720 is that it is a protocol proposal that has yet to go through a mailing list approval process. Feel free to unmark as a draft if I am mistaken here. |
That's fair. I just marked it as ready to indicate that it's ready for review, but it does still need to undergo the formal spec change process. These PRs are intended to serve as conversation starters around specific implementation details of the spec change. |
👍 I just wanted to avoid this accidentally getting merged early |
Mailing list discussion thread: https://lists.apache.org/thread/3kb82ypx99q96g84qv555l6x8r0bppyq |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @erratic-pattern -- I think this is looking quite good. I had some questions about the API design, but otherwise 👍
arrow-flight/src/sql/client.rs
Outdated
.map_err(status_to_arrow_error)? | ||
.unwrap(); | ||
// Attempt to update the stored handle with any updated handle in the DoPut result. | ||
// Not all servers support this, so ignore any errors when attempting to decode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this might silently ignore legitimate errors and I think it would be a good way to distinguish between a server not sending a response vs sending an invalid response.
If the server doesn't support sending back an updated handle, the put_results should be empty, right? So perhaps we could check for an empty response rather than ignoring the error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the logic here to not ignore legitimate errors and instead only look for empty responses instead.
@@ -617,7 +618,7 @@ impl FlightSqlService for FlightSqlServiceImpl { | |||
&self, | |||
_query: CommandPreparedStatementQuery, | |||
_request: Request<PeekableFlightDataStream>, | |||
) -> Result<Response<<Self as FlightService>::DoPutStream>, Status> { | |||
) -> Result<Option<DoPutPreparedStatementResult>, Status> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it the field on DoPutPreparedStatementResult
that is optional? It seems like this API would be cleaner and follow the rest of the API if it returned a DoPutPreparedStatementResult (and the client can handle / translate a missing message into a DoPutPreparedStatementResult)?
) -> Result<Option<DoPutPreparedStatementResult>, Status> { | |
) -> Result<DoPutPreparedStatementResult, Status> { |
Or maybe it is important to distinguish between the case where the server didn't send back any message from the case where the server sent back a message with an empty prepared handle?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a decision of whether or not we want to expressly forbid up-to-date servers from implementing the older version of the spec, even though clients still support it. I went with the more conservative decision of allowing existing implementations to continue doing what they were doing before without any major changes aside from changing their return value to Ok(None)
. That way they continue with the legacy behavior without being "locked out" of future crate updates.
A counterargument to this would be that it should be trivial for servers to simply return the existing handle so there's no need for this extra layer of backwards compatibility.
cmd.prepared_statement_handle, | ||
PREPARED_STATEMENT_HANDLE.as_bytes() | ||
); | ||
if self.stateless_prepared_statements { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to do this kind of testing (simulate both stateful and stateless server behavior) in the Go implementation as well, but I am less confident around the Arrow Go test suite and general Go testing practices.
adf8361
to
e8067f7
Compare
e8067f7
to
3dcbeda
Compare
TODO: update protobuf docs with latest changes to apache/arrow#40243 once the documentation in that PR has finalized |
The proposal for this specification change was approved on the Arrow dev mailing list. See thread here I've moved this PR out of draft status. |
…ments (#40243) documents changes for stateless management of FlightSQL prepared statement handles based on the design proposal described in #37720 * GitHub Issue: #37720 PRs for language implementations: * Rust: apache/arrow-rs#5433 * Go: #40311 Mailing list discussion: https://lists.apache.org/thread/3kb82ypx99q96g84qv555l6x8r0bppyq --------- Co-authored-by: David Li <[email protected]> Co-authored-by: Andrew Lamb <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again @erratic-pattern
Can you double check that the change to FlightSql.proto in this repo is the same as was merged into the arrow repo in apache/arrow#40243 ?
arrow-flight/src/sql/client.rs
Outdated
@@ -519,17 +521,37 @@ impl PreparedStatement<Channel> { | |||
.await | |||
.map_err(flight_error_to_arrow_error)?; | |||
|
|||
self.flight_sql_client | |||
// Attempt to update the stored handle with any updated handle in the DoPut result. | |||
// Not all servers support this, so ignore any errors when attempting to decode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment says errors are ignored, but the code doesn't seem to ignore errors. I wonder if I am misreading this or if the comment or code should be updated 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment says errors are ignored, but the code doesn't seem to ignore errors. I wonder if I am misreading this or if the comment or code should be updated 🤔
comments never lie ;)
updated this to explain that we ignore the lack of a response from legacy servers, rather than any error.
I've updated the protobuf docs to match the docs that were merged into arrow here apache/arrow#40243 Let me know if there's anything else left to address. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM -- thank you very much @erratic-pattern
…nts (apache#5433) * feat: stateless FlightSQL prepared statements * update protobuf and improve legacy behavior * Update arrow-flight/src/sql/server.rs Co-authored-by: Andrew Lamb <[email protected]> * make DoPutPreparedStatenentResult mandatory * update DoPutPreparedStatementResult docs to match arrow repo * update comment about legacy server behavior in DoPut --------- Co-authored-by: Andrew Lamb <[email protected]>
…nts (apache#5433) * feat: stateless FlightSQL prepared statements * update protobuf and improve legacy behavior * Update arrow-flight/src/sql/server.rs Co-authored-by: Andrew Lamb <[email protected]> * make DoPutPreparedStatenentResult mandatory * update DoPutPreparedStatementResult docs to match arrow repo * update comment about legacy server behavior in DoPut --------- Co-authored-by: Andrew Lamb <[email protected]>
…nts (apache#5433) * feat: stateless FlightSQL prepared statements * update protobuf and improve legacy behavior * Update arrow-flight/src/sql/server.rs Co-authored-by: Andrew Lamb <[email protected]> * make DoPutPreparedStatenentResult mandatory * update DoPutPreparedStatementResult docs to match arrow repo * update comment about legacy server behavior in DoPut --------- Co-authored-by: Andrew Lamb <[email protected]>
implements client changes for stateless management of FlightSQL prepared statement handles based on the design proposal described in apache/arrow#37720