htInfo(CancelFlightInfoRequest)
https://github.com/apache/arrow/pull/36009
If there is no more comment in a few days, I'll start voting
on this proposal.
Thanks,
--
kou
In
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Fri, 23 Jun
2023 13:40:56 -0400,
&quo
rrent specifications/implementations
>> to the followings:
>>
>> * Remove CloseFlightInfo (if nobody objects it)
>> * RefreshFlightEndpoint ->
>> RenewFlightEndpoint
>> * RenewFlightEndpoint(FlightEndpoint) ->
>> RenewFlightEndpoint(RenewFlightEndpointRequest)
>> *
nobody objects it)
> * RefreshFlightEndpoint ->
> RenewFlightEndpoint
> * RenewFlightEndpoint(FlightEndpoint) ->
> RenewFlightEndpoint(RenewFlightEndpointRequest)
> * CancelFlightInfo(FlightInfo) ->
> CancelFlightInfo(CancelFlightInfoRequest)
>
>
> Thanks,
&g
dpoint(RenewFlightEndpointRequest)
* CancelFlightInfo(FlightInfo) ->
CancelFlightInfo(CancelFlightInfoRequest)
Thanks,
--
kou
In
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Thu, 22 Jun
2023 12:51:55 -0400,
Matt Topol wrote:
>> That said, I think it's reaso
,
--
kou
In
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Wed, 21 Jun
2023 15:53:54 +0200,
Antoine Pitrou wrote:
>
> Ah... in JDBC, if the statement is something like an UPDATE or INSERT,
> than cancelling the statement is not the same thing as closi
hen
review/merge their implementations, how about updating our
changing process?
https://arrow.apache.org/docs/dev/format/Changing.html
Thanks,
--
kou
In
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Thu, 22 Jun
2023 08:55:33 +0200,
Antoine Pitrou 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
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
htInfo?
Thanks,
--
kou
In <0add20bd-34af-425f-8bdd-bcc609427...@app.fastmail.com>
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Wed, 21 Jun
2023 21:49:58 -0400,
"David Li" wrote:
>> So this may not be needed for now. How about accepting
nt-1578200076
>
>> * 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 meani
pendent anyway ("cancel" and
> "close" may have meaningful differences when putting/uploading data,
> not so much when getting/downloading data, IMHO?).
We're discussing this in another e-mail:
* https://lists.apache.org/thread/nndt2v7w49bcvfmwo0polv7k3srvm5n5
* https://lists.apache.o
d implementation related changes
separately, our CI will be broken temporary. Because our
implementations use auto-generated sources that are based on
*.proto.
Thanks,
--
kou
In
"Re: [DISCUSS][Format][Flight] Result set expiration support" on Wed, 21 Jun
2023 15:51:57 +0200,
Ah... in JDBC, if the statement is something like an UPDATE or INSERT,
than cancelling the statement is not the same thing as closing the
result set? The latter would probably just discard the result set but
still commit the results?
The problem is that Flight RPC doesn't have separate
I meant purely the changes to the "format" directory. It would probably
be better to have those in their own PR?
Le 21/06/2023 à 15:49, David Li a écrit :
Ah, sorry, it looks like the original linked PR is not this one. There is an
implementation for C++/Java/Go at
Ah, sorry, it looks like the original linked PR is not this one. There is an
implementation for C++/Java/Go at https://github.com/apache/arrow/pull/36009.
On Wed, Jun 21, 2023, at 09:49, David Li wrote:
> There is a PR linked in the original message, but here it is again:
>
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
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
Hi,
David provided the Java implementation. Thanks!
If anyone has any comments about this proposal, please share
them.
Thanks,
--
kou
In <20230619.151511.1159782462289578136@clear-code.com>
"[DISCUSS][Format][Flight] Result set expiration support" on Mon, 19 Jun 2023
Hi,
I would like to propose adding support for result set
expiration to Apache Arrow Flight. If anyone has comments
for this proposal, please share them at here or the issue
for this proposal:
https://github.com/apache/arrow/issues/35500
This is one of proposals in "[DISCUSS] Flight RPC/Flight
19 matches
Mail list logo
