Matt Topol
@vyasr @davidwendt I've got this up! There's still another test or two I need to add, but I figured it would be good to get this PR filed before the...
> Looks good overall. Do you also plan to include an overload that accepts an ArrowArray? I imagine it would be trivial but it would be handy for callers. That...
@vyasr Added `from_arrow_column` overload. Let me know if there's any other changes needed! :smile:
@vyasr Just to make sure I understand the suggestion, you're saying recursively spin through the `ArrowArray` and explicitly, and blindly, copy each buffer to the device using `cudaMemcpy` and then...
I don't think the test failures are my fault here. Is there anything else needed on my end to get this merged?
> For zero-copy you should be able wrap the arrow data in device memory with a cudf::column_view (and cudf::table_view) which are [non-owning data structures](https://github.com/rapidsai/cudf/blob/branch-24.04/cpp/doxygen/developer_guide/DEVELOPER_GUIDE.md#cudfcolumn_view). The issue is that it's not...
Before I go further working on it, could you take a look at my partial implementation in https://github.com/zeroshade/cudf-flight-ucx/blob/main/to_arrow.cc and let me know if you think that's a good direction to...
> Who owns the data after this call? Technically the data has shared ownership. The `ArrowDeviceArray` maintains a reference to the passed in `std::shared_ptr` to keep it alive until the...
The `ArrowDeviceArray` was introduced with arrow v13 or v14. You'll find it in the header file `` > I'm still puzzled by the lack of a type-id in these structures....
> `ArrowDeviceArray to_arrow_device_array(unique_ptr column)` in this context because an ownership transfer would indeed be the only way to get proper interop with other Arrow consumers that are expecting [a shared...