Re: [DISCUSS][Format][Flight] Result set expiration support

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

Re: [DISCUSS][Format][Flight] Result set expiration support

Hi, > It is generally recommended by the gRPC authors to have > separate request and response messages for each RPC Oh, I didn't know about it. Should we create CancelFlightInfoRequest/CloseFlightInfoRequest messages instead of using FlightInfo directly for CancelFlightInfo/CloseFlightInfo? Tha

Re: [DISCUSS][Format][Flight] Result set expiration support

> So this may not be needed for now. How about accepting a > specific request message instead of FlightEndpoint directly > as "PersistFlightEndpoint" input? I'm in favor of this on principle. It is generally recommended by the gRPC authors to have separate request and response messages for each R

Re: [DISCUSS][Format][Flight] Result set expiration support

Hi, > * "RefreshFlightEndpoint" suggests the server will recompute (refresh) > the results; instead I would suggest "PersistFlightEndpoint" Thanks for the suggestion. But I feel that "persist" doesn't have expiration time. (NOTE: I'm not a native English speaker.) How about the followings? *

Re: [DISCUSS][Format][Flight] Result set expiration support

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

Re: [VOTE] Kevin Gurney for Committer

Oh, sorry... I sent this to the wrong mailing list... Please ignore this... Thanks, -- kou In <20230622.085709.224766127116222688@clear-code.com> "[VOTE] Kevin Gurney for Committer" on Thu, 22 Jun 2023 08:57:09 +0900 (JST), Sutou Kouhei wrote: > Hi, > > I propose to invite Kevin Gurn

[VOTE] Kevin Gurney for Committer

Hi, I propose to invite Kevin Gurney to be a committer. See discussion here [1]. [ ] +1 : Invite Kevin Gurney to become a committer [ ] +0: ... [ ] -1: I disagree because ... The vote will be open for at least 48 hours. [1] https://lists.apache.org/thread/5ndpc74nvb4dwy2fxho1cwhmdqwg3922 Thank

Re: [DISCUSS] ADBC 0.5.1 patch release?

I'd be willing to do this. It looks like the conference starts 6/26? So if all goes well, I can kick off a release later tonight or early tomorrow and we should be ready just before the conference. On Wed, Jun 21, 2023, at 16:38, Matt Topol wrote: > Given the upcoming Snowflake Summit talk on AD

[DISCUSS] ADBC 0.5.1 patch release?

Given the upcoming Snowflake Summit talk on ADBC with the Snowflake driver, and potential deadlock condition addressed by [1], it might make sense for us to do a v0.5.1 patch release of ADBC. Unfortunately I only discovered the issue just as the voting for 0.5.0 closed and the release was finalize

[Python][Discuss] PyArrow Dataset as a Python protocol

Hello Arrow devs, I have drafted a PR defining an experimental protocol which would allow third-party libraries to imitate the PyArrow Dataset API [5]. This protocol is intended to endorse an integration pattern that is starting to be used in the Python ecosystem, where some libraries are providin

Re: [DISC] ADBC 1.1.0 API revision

Two updates here: - We've merged the C# and Rust PRs. They were not in the recent release, but are in the source tree, and I hope we can continue iterating on them. (A few contributors have been actively working on C#.) - A second PR [1] has been filed that proposes new APIs for ADBC around met

Arrow community meeting June 21 at 16:00 UTC

Our next biweekly Arrow community meeting is today at 16:00 UTC / 12:00 EDT. Zoom meeting URL: https://zoom.us/j/87649033008?pwd=SitsRHluQStlREM0TjJVYkRibVZsUT09 Meeting ID: 876 4903 3008 Passcode: 958092 Meeting notes will be captured in this Google Doc: https://docs.google.com/document/d/1xrji8

Re: [DISCUSS][Format][Flight] Result set expiration support

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 noti

Re: [DISCUSS][Format][Flight] Result set expiration support

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 https://github.com/apach

Re: [DISCUSS][Format][Flight] Result set expiration support

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: > https://github.com/ap

Re: [DISCUSS][Format][Flight] Result set expiration support

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

Re: [DISCUSS][Format][Flight] Result set expiration support

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 "Pe

Re: [VOTE] Release Apache Arrow nanoarrow 0.2.0 - RC1

RPATH didn't work any better, even though `lddtree` finds all dependencies: https://gist.github.com/pitrou/ce712f6dd18df9b8fb55272d7966d6f3 Le 21/06/2023 à 05:00, Sutou Kouhei a écrit : Hi, I think that you needed to specify "-DCMAKE_INSTALL_RPATH=${CONDA_PREFIX}/lib" when you build Apache A

Re: [DISCUSS][Format] Draft implementation of string view array format

I hope implementations don't start exposing non-standard datatypes over the C Data Interface (apart from extension types, of course). I would also be wary of exposing non-standard datatypes in the official Arrow C++ implementation. Regards Antoine. Le 21/06/2023 à 14:27, Benjamin Kietzma

[RESULT] Release Apache Arrow ADBC 0.5.0 - RC0

Re-sending with [RESULT] in the title. Post-release tasks: [x] Close the GitHub milestone/project [x] Add the new release to the Apache Reporter System [x] Upload source release artifacts to Subversion [x] Create the final GitHub release [x] Update website [x] Upload wheels/sdist to PyPI [x] Publ

Re: [DISCUSS][Format] Draft implementation of string view array format

> Ben, at one point there was some discussion that this might be a c-data > only type. However, I believe that was based on the raw pointers > representation. What you've proposed here, if I understand correctly, is > an index + offsets representation and it is suitable for IPC correct? > (e.g.