There is a PR linked in the original message, but here it is again: https://github.com/apache/arrow/pull/36009
Cancel and Close are close semantically, but Cancel is meant for when the (client thinks that) computation is still ongoing, while Close is meant to free server resources after reading a result set. (For example, JDBC has Statement#cancel [1] and ResultSet#close [2].) That said, I think it's reasonable to only have Cancel at the protocol level. [1]: https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#cancel-- [2]: https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSet.html#close-- On Wed, Jun 21, 2023, at 09:35, Antoine Pitrou wrote: > Hi Kou, > > Can we have an actual PR with the proposed gRPC field, method and > docstring additions? > > Regardless, I have some comments and questions: > > * "RefreshFlightEndpoint" suggests the server will recompute (refresh) > the results; instead I would suggest "PersistFlightEndpoint" > > * Perhaps "PersistFlightEndpoint" can take an optional > "suggested_expiration" timestamp, which the server is free to ignore > (some clients may only need to extend the expiration by two minutes, > others by two days...) > > * Does the client potentially have to call "PersistFlightEndpoint" on > each returned endpoint? Can it pass several endpoints at once? > > * What is the expected difference between "CancelFlightInfo" and > "CloseFlightInfo"? Both seem to have a similar effect, and the exact > behaviour will probably be server-dependent anyway ("cancel" and "close" > may have meaningful differences when putting/uploading data, not so much > when getting/downloading data, IMHO?). > > Regards > > Antoine. > > > > Le 21/06/2023 à 02:28, Sutou Kouhei a écrit : >> Hi, >> >> David provided the Java implementation. Thanks! >> >> If anyone has any comments about this proposal, please share >> them. >> >> >> Thanks,
