Hi Flavio,
Yes I think the handling of the DateTime in Flink can be better when
dealing with DATE TIME type of systems.
There are several limitations Jingsong briefly mentioned about
java.util.Date. Some of these limitations are even affecting correctness of
the results (e.g. Gregorian vs Julian c
Hi Flavio,
yes I agree. This check is a bit confusing. The initial reason for that
was that sql.Time, sql.Date, and sql.Timestamp extend from util.Date as
well. But handling it as a generic type as Jingson mentioned might be
the better option in order to write custom UDFs to handle them.
Reg
Of course there are java.sql.* and java.time.* in Java but it's also true
that most of the times the POJOs you read come from an external (Maven) lib
and if such POJOs contain date fields you have to create a local version of
that POJO having the java.util.Date fields replaced by a java.sql.Date
ve
Flink 1.9 blink runner will support it as Generic Type,
But I don't recommend it. After all, there are java.sql.Date and java.time.* in
Java.
Best, JingsongLee
--
From:Flavio Pompermaier
Send Time:2019年7月8日(星期一) 15:40
To:JingsongL
I think I could do it for this specific use case but isn't this a big
limitation of Table API?
I think that java.util.Date should be a first class citizen in Flink..
Best,
Flavio
On Mon, Jul 8, 2019 at 4:06 AM JingsongLee wrote:
> Hi Flavio:
> Looks like you use java.util.Date in your pojo, Now
Hi Flavio:
Looks like you use java.util.Date in your pojo, Now Flink table not support
BasicTypeInfo.DATE_TYPE_INFO because of the limitations of some judgments in
the code.
Can you use java.sql.Date?
Best, JingsongLee
--
From:F
