Add support of converting FixedSizeBinaryArray to DecimalArray

[HaoYang670]

Signed-off-by: remzi 13716567376yh@gmail.com

Which issue does this PR close?

None.
Related to #2026.

Rationale for this change

1. converting from fixed size binary to decimal is safer than converting from fixed size list to decimal.
2. The Decimal builder will use this function in the future.

What changes are included in this PR?

Add new function from_fixed_size_binary_array

Are there any user-facing changes?

No.

[liukun4515]

@HaoYang670 from the comments, why not change the builder for decimal in this pr.
It's make sense to me with these two changes the one pull request.

[HaoYang670]

@liukun4515 from_fixed_size_binary_array is not just for the decimal builder. It is also a public function which users can use it directly.
Also, small PR is easier to review.

[liukun4515]

But from this message, this function is just used to convert to the decimal array.
@HaoYang670

[HaoYang670]

cc @viirya

[tustvold]

Looks good to me, although I am a little bit confused where we have ended up w.r.t validating decimals in ArrayData

[tustvold]

You could use the new APIs for this

let builder = v
    .into_data()
    .into_builder()
    .data_type(DataType::Decimal(precision, scale));
Self::from(unsafe { builder.build_unchecked() });

Saves some clones and is slightly less verbose

[HaoYang670]

Looks good to me, although I am a little bit confused where we have ended up w.r.t validating decimals in ArrayData

Thank you @tustvold. The decimal values will be validated in the function validate_values if the features=force_validate is set.
BTW, when we get a decimal value from Decimal::value(i), we also don't validate the range.

[tustvold]

if the features=force_validate is set.

This is very much a testing only feature, this enables validation everywhere and will absolutely tank performance. It is a MIRI-light, meant for integration testing and not production usage.

BTW, when we get a decimal value from Decimal::value(i), we also don't validate the range.

That is likely because the general assumption within arrow-rs is you can't construct an invalid ArrayData without using an unsafe API. This does not appear to be true of Decimal, at least at the moment

[HaoYang670]

Hmm, the failure seems related to the CI env.
https://github.com/apache/arrow-rs/runs/7313219137?check_suite_focus=true#step:3:12

Also find the same failrue in #2056

[codecov-commenter]

Codecov Report

Merging #2041 (7c12db4) into master (ca5fe7d) will increase coverage by 0.06%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##           master    #2041      +/-   ##
==========================================
+ Coverage   83.54%   83.61%   +0.06%     
==========================================
  Files         222      223       +1     
  Lines       58186    58567     +381     
==========================================
+ Hits        48612    48970     +358     
- Misses       9574     9597      +23     

Impacted Files	Coverage Δ
arrow/src/array/array_decimal.rs	90.59% <85.71%> (-0.53%)	⬇️
parquet/src/file/serialized_reader.rs	93.58% <0.00%> (-1.76%)	⬇️
arrow/src/datatypes/datatype.rs	64.05% <0.00%> (-1.26%)	⬇️
parquet/src/file/metadata.rs	94.70% <0.00%> (-0.69%)	⬇️
parquet_derive/src/parquet_field.rs	65.98% <0.00%> (-0.23%)	⬇️
arrow/src/array/mod.rs	100.00% <0.00%> (ø)
parquet/src/util/page_util.rs	100.00% <0.00%> (ø)
arrow/src/compute/kernels/filter.rs	88.08% <0.00%> (+0.03%)	⬆️
arrow/src/array/array_dictionary.rs	92.09% <0.00%> (+0.03%)	⬆️
parquet/src/column/writer.rs	91.53% <0.00%> (+0.05%)	⬆️
... and 6 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 ca5fe7d...7c12db4. Read the comment docs.

[HaoYang670]

@alamb could you please help to look at what causes the CI failure?

[HaoYang670]

The failure randomly occurred, such as in #2064.
https://github.com/apache/arrow-rs/runs/7335882941?check_suite_focus=true

[alamb]

Thanks @HaoYang670 -- I don't really have any idea what is going on with the windows builders. I have restarted the failed job and hopefully the tests will pass on a subsequent run

[ursabot]

Benchmark runs are scheduled for baseline = 7fff23f and contender = 9d8f0c9. 9d8f0c9 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[HaoYang670]

Thank you for your review @liukun4515 @viirya @tustvold @alamb !