Fix: Support for e notation using existing parse_decimal in string to decimal conversion #6905
Conversation
himadripal
changed the title
error message changed.
|
@andygrove @viirya @tustvold please take a first look. The one failing test will be fixed once I add the rounding logic in parse-e-notation function. |
| .and_then(|v| T::validate_decimal_precision(v, precision).map(|_| v)) | ||
| parse_decimal::<T>(v, precision, scale).map_err(|_| { | ||
| ArrowError::CastError(format!( | ||
| "Cannot cast string '{}' to decimal type of precision {} and scale {}", |
There was a problem hiding this comment.
T:DATA_TYPE shows default Decimal(38,10) or Decimal256(76,..) in the error message, hiding the precision and scale provided for cast.
| @@ -230,6 +231,7 @@ where | |||
| )?)) | |||
| } | |||
|
|
|||
| #[allow(dead_code)] | |||
There was a problem hiding this comment.
This fails in clippy, hence added #[allow(dead_code)], there is no use, if required we can remove it and cover existing tests with parse_decimal.
There was a problem hiding this comment.
We should remove this and port the tests, to ensure we aren't losing test coverage / accidentally changing behaviour
Clippy did not complain and tests are passing, except one which I'm working on - rounding for e-notation. Would any others build task catch it? |
Which issue does this PR close?
Closes #. apache/datafusion#10315
Rationale for this change
What changes are included in this PR?
Completed :
Pending :
Are there any user-facing changes?