ARROW-12411: [Rust] Create RecordBatches from Iterators

[alamb]

(Here is a PR to the new arrow crate to see what how this process is working!)
Closes #210

Rationale / Usecase:

While writing tests (both in IOx and in DataFusion) where I need a single RecordBatch, I often find myself doing something like this (copied directly from IOx source code):

let schema = Arc::new(Schema::new(vec![
    ArrowField::new("float_field", ArrowDataType::Float64, true),
    ArrowField::new("time", ArrowDataType::Int64, true),
]));

let float_array: ArrayRef = Arc::new(Float64Array::from(vec![10.1, 20.1, 30.1, 40.1]));
let timestamp_array: ArrayRef = Arc::new(Int64Array::from(vec![1000, 2000, 3000, 4000]));

let batch = RecordBatch::try_new(schema, vec![float_array, timestamp_array])
    .expect("created new record batch");

This is annoying because I have to redundantly (and verbosely) encode the information that float_field is a Float64 both in the Schema and the Float64Array

I would much rather be able to construct RecordBatches using a more Rust like style to avoid the the redundancy and reduce the amount of typing / redundancy:

Proposed Change

As suggested in the comments from @returnString @nevi-me @jorgecarleitao in the draft PR: apache/arrow#10063 add try_from_iter and try_iter_with_null functions

let record_batch = RecordBatch::try_from_iter(vec![
  ("a", Arc::new(a) as ArrayRef),
  ("b", Arc::new(b) as ArrayRef)
]).expect("valid conversion");

TryFrom Implementation

Note I would really like to add aTryFrom implementation so I could write

let record_batch: RecordBatch = vec![
  ("a", Arc::new(a) as ArrayRef),
  ("b", Arc::new(b) as ArrayRef)
].try_into().expect("valid conversion");

However, when I tried to do so (with the following):

impl <I,F> TryFrom<I> for RecordBatch
where
     I: IntoIterator<Item=(F, ArrayRef)>,
     F: AsRef<str>,
{
    type Error = ArrowError;

    fn try_from(value: I) -> std::result::Result<Self, Self::Error> {
        Self::try_from_iter(value)
    }
}

I got the following compiler error

     = note: conflicting implementation in crate `core`:
            - impl<T, U> TryFrom<U> for T
              where U: Into<T>;

Which appears to be a limitation of the Rust typesystem / compiler: See rust-lang/rust#50133. Any help / suggestions from reviewers would be most appreciated.

[codecov-commenter]

Codecov Report

Merging #7 (3933a28) into master (3f13806) will increase coverage by 0.01%.
The diff coverage is 81.34%.

❗ Current head 3933a28 differs from pull request most recent head f235bec. Consider uploading reports for the commit f235bec to get more accurate results

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
+ Coverage   82.47%   82.49%   +0.01%     
==========================================
  Files         162      162              
  Lines       43414    43454      +40     
==========================================
+ Hits        35805    35846      +41     
+ Misses       7609     7608       -1     

Impacted Files	Coverage Δ
arrow-flight/examples/server.rs	0.00% <0.00%> (ø)
arrow-flight/src/arrow.flight.protocol.rs	0.00% <0.00%> (ø)
arrow-flight/src/utils.rs	0.00% <0.00%> (ø)
arrow-pyarrow-integration-testing/src/lib.rs	0.00% <0.00%> (ø)
arrow/src/alloc/types.rs	0.00% <0.00%> (ø)
arrow/src/array/builder.rs	85.29% <ø> (ø)
arrow/src/array/iterator.rs	95.80% <ø> (ø)
arrow/src/array/null.rs	86.66% <ø> (ø)
arrow/src/array/ord.rs	59.28% <ø> (ø)
arrow/src/array/raw_pointer.rs	100.00% <ø> (ø)
... and 94 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b3298a...f235bec. Read the comment docs.

[alamb]

I rewrote master to remove the history of the other languages (and 50MB of history). This means this PR needs to be "rebased" against the current master.

The best way I found to do this was to find the relevant commits (via git log) and then cherry-pick them one at a time. Specifically, for this PR:

git reset --hard apache/master
git cherry-pick 5d3c337710b89871a46f6e623bad8c9e05419ed2
git push -f alamb

[jorgecarleitao]

We had to perform a small re-write of master. The commits may look a bit odd, but it should not cause conflicts. Could you kindly rebase this against the latest master to make it easier to review?

[alamb]

fyi @returnString

[returnString]

Nice, looking forward to less ceremony in test cases 👍

[jorgecarleitao]

Sorry, I thought I had approved this, but it was prob. on the old repo. Thanks for the ping.

This looks great, including great documentation and tests! 👍

[jorgecarleitao]

fyi, I think that this closes #210 , could you add it to the description so github picks it up?