One small difference seems to be that Close is idempotent and Cancel is not.
> void cancel() > throws SQLException > > Cancels this Statement object if both the DBMS and driver support aborting an SQL statement. This method can be used by one thread to cancel a statement that is being executed by another thread. > > Throws: > SQLException - if a database access error occurs or this method is called on a closed Statement In other words, with cancel, you can display an error to the user if the statement is already finished (and thus was not able to be canceled). However, I don't know if that is significant at all. On Fri, Jun 23, 2023 at 12:17 AM Sutou Kouhei <k...@clear-code.com> wrote: > Hi, > > Thanks for sharing your thoughts. > > OK. I'll change the current specifications/implementations > to the followings: > > * Remove CloseFlightInfo (if nobody objects it) > * RefreshFlightEndpoint -> > RenewFlightEndpoint > * RenewFlightEndpoint(FlightEndpoint) -> > RenewFlightEndpoint(RenewFlightEndpointRequest) > * CancelFlightInfo(FlightInfo) -> > CancelFlightInfo(CancelFlightInfoRequest) > > > Thanks, > -- > kou > > In <CAH4123YJaP7ZKZAUmznZ0CSsdb+6tsOJzvFJGiqEd=bcwkz...@mail.gmail.com> > "Re: [DISCUSS][Format][Flight] Result set expiration support" on Thu, 22 > Jun 2023 12:51:55 -0400, > Matt Topol <zotthewiz...@gmail.com> wrote: > > >> That said, I think it's reasonable to only have Cancel at the protocol > > level. > > > > I'd be in favor of only having Cancel too. In theory calling Cancel on > > something that has already completed should just be equivalent to calling > > Close anyways rather than requiring a client to guess and call Close if > > Cancel errors or something. > > > >> So this may not be needed for now. How about accepting a > >> specific request message instead of FlightEndpoint directly > >> as "PersistFlightEndpoint" input? > > > > I'm also in favor of this. > > > >> I think Refresh was fine, but if there's confusion, I like Kou's > > suggestion of Renew the best. > > > > I'm in the same boat as David here, I think Refresh was fine but like the > > suggestion of Renew best if we want to avoid any confusion. > > > > > > > > On Thu, Jun 22, 2023 at 2:55 AM Antoine Pitrou <anto...@python.org> > wrote: > > > >> > >> Doesn't protobuf ensure forwards compatibility? Why would it break? > >> > >> At worse, you can include the changes necessary for it to compile > >> cleanly, without adding support for the new fields/methods? > >> > >> > >> Le 22/06/2023 à 02:16, Sutou Kouhei a écrit : > >> > Hi, > >> > > >> > The following part in the original e-mail is the one: > >> > > >> >> https://github.com/apache/arrow/pull/36009 is an > >> >> implementation of this proposal. The pull requests has the > >> >> followings: > >> >> > >> >> 1. Format changes: > >> >> * format/Flight.proto > >> >> > >> > https://github.com/apache/arrow/pull/36009/files#diff-53b6c132dcc789483c879f667a1c675792b77aae9a056b257d6b20287bb09dba > >> >> * format/FlightSql.proto > >> >> > >> > https://github.com/apache/arrow/pull/36009/files#diff-fd4e5266a841a2b4196aadca76a4563b6770c91d400ee53b6235b96da628a01e > >> >> > >> >> 2. Documentation changes: > >> >> docs/source/format/Flight.rst > >> >> > >> > https://github.com/apache/arrow/pull/36009/files#diff-839518fb41e923de682e8587f0b6fdb00eb8f3361d360c2f7249284a136a7d89 > >> > > >> > We can split the part to a separated pull request. But if we > >> > split the part and merge the pull requests for format > >> > related changes and implementation related changes > >> > separately, our CI will be broken temporary. Because our > >> > implementations use auto-generated sources that are based on > >> > *.proto. > >> > > >> > > >> > Thanks, > >> >
