Mailing-List: contact dev-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
MIME-Version: 1.0
In-Reply-To: <HE1PR03MB1305C8DCA73EDDA03B71B196F3AD0@HE1PR03MB1305.eurprd03.prod.outlook.com>
References: <HE1PR03MB1305C8DCA73EDDA03B71B196F3AD0@HE1PR03MB1305.eurprd03.prod.outlook.com>
From: Fabian Hueske <fhueske@gmail.com>
Date: Fri, 28 Oct 2016 17:16:31 +0200
Message-ID: <CAAdrtT30uRtKK-cFqLp3zgc==gxUUnQfdst8u3yAFMFMHqH_3Q@mail.gmail.com>
Subject: Re: trouble with type casting
To: "dev@flink.apache.org" <dev@flink.apache.org>
Content-Type: multipart/alternative; boundary=001a113ec4da9dfe11053fee59c6
archived-at: Fri, 28 Oct 2016 15:17:13 -0000

--001a113ec4da9dfe11053fee59c6
Content-Type: text/plain; charset=UTF-8

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 <Anton_Solovev@epam.com>:

>
> 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
>
>
>

--001a113ec4da9dfe11053fee59c6--