Thanks for confirming! Honestly I support to treat timestamp field as
special and restrict modification (the way DataStream API does), but I
agree the new approach could be more natural to unify the semantic of SQL
for both batch and stream.
Thanks again,
Jungtaek Lim (HeartSaVioR)
On Tue, Apr 28
Hi Jungtaek,
Yes. Your understanding is correct :)
Best,
Jark
On Tue, 28 Apr 2020 at 11:58, Jungtaek Lim
wrote:
> Thanks Kurt and Jark for the detailed explanation! Pretty much helped to
> understand about FLIP-66.
>
> That sounds as Flink won't leverage timestamp in StreamRecord (which is
> h
Thanks Kurt and Jark for the detailed explanation! Pretty much helped to
understand about FLIP-66.
That sounds as Flink won't leverage timestamp in StreamRecord (which is
hidden and cannot modified easily) and handles the time semantic by the
input schema for the operation, to unify the semantic b
Hi Jungtaek,
Kurt has said what I want to say. I will add some background.
Flink Table API & SQL only supports to define processing-time attribute and
event-time attribute (watermark) on source, not support to define a new one
in query.
The time attributes will pass through the query and time-base
The current behavior is later. Flink gets time attribute column from source
table, and tries to analyze and keep
the time attribute column as much as possible, e.g. simple projection or
filter which doesn't effect the column
will keep the time attribute, window aggregate will generate its own time
