ARROW-10034: [Rust] Fix Rust build on master

[andygrove]

Reverts ARROW-9977 and fixes one other conflict.

I was seeing compilation errors like this:

error[E0599]: no method named `value` found for reference `&array::array::StringArray` in the current scope
  --> arrow/src/compute/kernels/aggregate.rs:39:35
   |
39 |                 let item = $array.value(i);
   |                                   ^^^^^ method not found in `&array::array::StringArray`

[andygrove]

@jorgecarleitao fyi

[andygrove]

build error seems unrelated so I am going to go ahead and merge this

[jorgecarleitao]

Thanks a lot for the quick response on solving this.

One was related to a new trait in Arrow, StringArrayOps, that has .value(i) -> &str, and is needed when using value in strings, in the commit for take.

The other one is related to the Ops in logical plans.

Essentially, this is all related to multiple merges, with backward incompatible changes on them.

@andygrove , is there anything we can do to help mitigating this during merge of multiple merges?

One idea is to have a WARNING in the PR text that the merge is backward incompatible, so that the committer knows of potential conflicts with other merges.

Another idea is to first perform the merges locally, one by one, and then push a branch with those changes to test them in integration, and then merge them at once.

[andygrove]

I think I will start testing each PR locally now, after merging latest from master. There is quite a bit of process in place so it is important that PRs are merged to master individually.

…

On Thu, Sep 17, 2020, 7:55 PM Jorge Leitao ***@***.***> wrote: Thanks a lot for the quick response on solving this. One was related to a new trait in Arrow, StringArrayOps, that has .value(i) -> &str, and is needed when using value in strings, in the commit for take . The other one is related to the Ops in logical plans. Essentially, this is all related to multiple merges, with backward incompatible changes on them. @andygrove <https://github.com/andygrove> , is there anything we can do to help mitigating this during merge of multiple merges? One idea is to have a WARNING in the PR text that the merge is backward incompatible, so that the committer knows of potential conflicts with other merges. Another idea is to first perform the merges locally, one by one, and then push a branch with those changes to test them in integration, and then merge them at once. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHEBREOAR5VEFXSRKRONFLSGK42NANCNFSM4RRFKIAA> .