Re: [Flight Format] Authentication Redesign

Looking towards the future a bit, I don't see some of the facilities we used for the Java code in the C++ Flight port. Primarily the use of CallOptions -- I don't see existing functionality for wrapping the gRPC stub within the context of a single request. I do see that we pass in FlightCallOptions

Re: Arrow Dataset API on Ceph

Hi Ben, > > Our main concern is that this new arrow::dataset::RadosFormat class will > be > > deriving from the arrow::dataset::FileFormat class, which seems to raise > a > > conceptual mismatch as there isn’t really a RADOS format > > IIUC RADOS doesn't interact with a filesystem directly, so Ra

Re: [FlightRPC] Add a "Flight SQL" extension on top of FlightRPC

I haven't been able to scrutinize the details greatly, but I am supportive of this effort, otherwise we may end up with many database systems and vendors implementing Flight in different ways. It would be nice if there was a built-in SQL client layer that we ship in C++ (and its bindings), Java, an

Re: Floating-point order

I agree that users should have the capability to determine their own way, but with Arrow going more into the direction of providing compute building blocks (kernels), a choice must be made, e.g., when it comes to sorting, computing a mean, etc. Certainly -Inf and Inf are easy to put in the row, bu

Re: Arrow sync call September 2 at 12:00 US/Eastern, 16:00 UTC

Attendees: James Duong Jörn Horstmann Kenneth Jung Ben Kietzman Micah Kornfield Tiffany Lam Wes McKinney Rok Mihevc Ryan Murray Ryan Nicholson Brendan Niebruegge Antoine Pitrou Nick Poorman Prudhvi Porandla Neal Richardson Keerat Singh Charlene Solonynka Sven Wagner-Boysen Andrew Wieteska Discus

Re: [FlightRPC] Add a "Flight SQL" extension on top of FlightRPC

Hello everyone, Here is a link to the slides I would like to discuss this morning. Take care, Ryan Nicholson On Tue, Sep 1, 2020 at 4:02 PM Ryan Nicholson wrote: > Thank you to all who have v

[NIGHTLY] Arrow Build Report for Job nightly-2020-09-02-0

Arrow Build Report for Job nightly-2020-09-02-0 All tasks: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-09-02-0 Failed Tasks: - test-conda-python-3.7-hdfs-2.9.2: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-09-02-0-github-test-conda-pyt

Re: [DISCUSS] Big Endian support in Arrow

Le 01/09/2020 à 23:26, Sutou Kouhei a écrit : > > Note that we need qemu-user-static 2.12 or later and > binfmt-support 2.1.7 or later. Ubuntu 18.10 or later ships > them. Ah, unfortunately I'm on Ubuntu 18.04. Regards Antoine.

Re: Floating-point order

Well, Inf and -Inf are already ordered ;-) Nan is, as usual, a can of worms. Ordering probably doesn't belong in the Arrow spec (which is only concerned with representing data, not processing it). In any case, I agree that it makes sense to handle all NaNs as equal when implementing comparison

Re: Rust/Datafusion sort kernel issues

Would it perhaps make sense to define the total order for non-numbers (NaN, Inf, -Inf) globally (i.e., in the spec or in Arrow itself) so that the behavior is the same across all languages? On Fri, Aug 28, 2020 at 7:42 PM Andy Grove wrote: > Hi Jörn, > > I agree with your concerns about NaN. The