trouble with type casting

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

trouble with type casting

Anton Solovev

I'm working on flink-4743 issue
I tried write tests as Fabian suggested me https://github.com/apache/flink/pull/2686#discussion_r85218584
and figure out that there is no implicit conversion of bigDecimal to double in table api.
"power" function accept only double as operands.

all is okay when run the function with sql api - "power(bigDecimal, double)" - a CallGenerator creates casting to double
when running the function with table api - 'bigDecimal.power('double)
it throws ValidationException (fails on input type checking), because of TypeCoercion#canSafelyCast() cannot allow to cast bigDecimal to double

what options I have?
1) let it cast with lose of information
2) don't use bigDecimal in functions, or cast it manually
3) create somewhere a new functions that accept bigDecimal as operand
4) any ideas?

Best,
Anton


Reply | Threaded
Open this post in threaded view
|

Re: trouble with type casting

Fabian Hueske-2
Hi Anton,

it seems that the Table API validation is more strict than Calcite's SQL
validator (maybe because it is not aware of the actual implementation).
In principle, it is correct to prevent the auto-casting from BigDecimal to
double.

I think it is fine to request an explicit cast from users (and also add
this cast in the test).
In addition we should make sure that the error message helps the user to
add the necessary cast.

What do you think?

Best, Fabian

2016-10-28 11:42 GMT+02:00 Anton Solovev <[hidden email]>:

>
> I'm working on flink-4743 issue
> I tried write tests as Fabian suggested me https://github.com/apache/
> flink/pull/2686#discussion_r85218584
> and figure out that there is no implicit conversion of bigDecimal to
> double in table api.
> "power" function accept only double as operands.
>
> all is okay when run the function with sql api - "power(bigDecimal,
> double)" - a CallGenerator creates casting to double
> when running the function with table api - 'bigDecimal.power('double)
> it throws ValidationException (fails on input type checking), because of
> TypeCoercion#canSafelyCast() cannot allow to cast bigDecimal to double
>
> what options I have?
> 1) let it cast with lose of information
> 2) don't use bigDecimal in functions, or cast it manually
> 3) create somewhere a new functions that accept bigDecimal as operand
> 4) any ideas?
>
> Best,
> Anton
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: trouble with type casting

Anton Solovev
I agree with you, Fabian.
I will add a small hint in exception and cast bigDecimal manually in test cases


-----Original Message-----
From: Fabian Hueske [mailto:[hidden email]]
Sent: Friday, October 28, 2016 7:17 PM
To: [hidden email]
Subject: Re: trouble with type casting

Hi Anton,

it seems that the Table API validation is more strict than Calcite's SQL validator (maybe because it is not aware of the actual implementation).
In principle, it is correct to prevent the auto-casting from BigDecimal to double.

I think it is fine to request an explicit cast from users (and also add this cast in the test).
In addition we should make sure that the error message helps the user to add the necessary cast.

What do you think?

Best, Fabian

2016-10-28 11:42 GMT+02:00 Anton Solovev <[hidden email]>:

>
> I'm working on flink-4743 issue
> I tried write tests as Fabian suggested me https://github.com/apache/
> flink/pull/2686#discussion_r85218584
> and figure out that there is no implicit conversion of bigDecimal to
> double in table api.
> "power" function accept only double as operands.
>
> all is okay when run the function with sql api - "power(bigDecimal,
> double)" - a CallGenerator creates casting to double when running the
> function with table api - 'bigDecimal.power('double) it throws
> ValidationException (fails on input type checking), because of
> TypeCoercion#canSafelyCast() cannot allow to cast bigDecimal to double
>
> what options I have?
> 1) let it cast with lose of information
> 2) don't use bigDecimal in functions, or cast it manually
> 3) create somewhere a new functions that accept bigDecimal as operand
> 4) any ideas?
>
> Best,
> Anton
>
>
>