Hi David and Antoine,
Thanks for your input. On past experience talking to some other Arrow / Spark
developers, we anticipate that it would take a long time to get into Spark. Our
plan was to build up a user base in the Arrow community before submitting for
inclusion to Spark. Is there a place
Hello!
I am trying to implement an ExecNode in Acero that receives the input
batch, writes the batch to the FlightStreamWriter and then passes the batch
to the downstream node.
Looking at the API, I am thinking of doing sth like :
void InputReceived(ExecNode* input, ExecBatch batch) {
# turn
Hi Li,
One way I've seen (which hopefully is the right way) is invoking
`ExecNode::ErrorIfNotOk(Status)`. If `WriteRecordBatch` returns a `Status` then
just pass it; if it returns a `Result` then you can pass its `.status()`.
Yaron.
From: Li Jin
Sent: Tuesday,
Yes. Something like:
if (ErrorIfNotOk(flight_writer->WriteRecordBatch(...))) return;
Today this method calls `output->ErrorReceived(...)`. The original
idea (I think) is that, possibly, a downstream node could "handle" the
error. However, in practice, nothing does that, and all errors
propagat
Hi everyone,
We recently had some discussions about parsing expressions. I currently have a
PR [1] up for that taking into account the feedback. Next I wanted to tackle
something for ExecPlans, as manually specifying one using code is currently
cumbersome. I’m currently deciding between 2 varian
Given the probable need for IP clearance, getting it into Arrow would also be a
Process(TM) unfortunately. We also don't really have a great place for "not
quite in tree" projects; there have been discussions of a 'contrib' repo in the
past, but nothing has materialized.
That said - have you sh
Hi,
> However, I think we need to be very careful in how we brand the
> alternative, and think proactively about what terminology we want to be
> used (and which terms to use in APIs, ..). Because I think the "IPC" aspect
> of the naming can also become confusing (IPC is a generic term, does not
>
Hi,
Can we define our maintenance policy?
For example, we maintain the last 3 major releases:
* We maintain 7.Y.Z, 8.Y.Z and 9.Y.Z when the latest major
release is 9.0.0
* We may release 7.Y.Z, 8.Y.Z or 9.Y.Z when we find a
problem such as a security vulnerability in 7.Y.Z, 8.Y.Z or
9.Y.Z
*
