[
https://issues.apache.org/jira/browse/FLINK-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649915#comment-16649915
]
Fabian Hueske commented on FLINK-8578:
--------------------------------------
I proposed the \{{.upsertOrder}} to distinguish cases where a table had two
different time attributes. We could of course restrict upsert tables to only
support one time attribute.
However, I'm not sure if we would prohibit legit use cases with such a
restriction. For example, a data stream could not be converted into a proc-time
upsert table while extracting the event-time attribute from the StreamRecord.
Btw. did we discuss what should happen with time attributes after the upsert
conversion? Do they lose their time-attribute properties, i.e., is the
proc-time attribute materialized?
> Implement rowtime DataStream to Table upsert conversion.
> --------------------------------------------------------
>
> Key: FLINK-8578
> URL: https://issues.apache.org/jira/browse/FLINK-8578
> Project: Flink
> Issue Type: Sub-task
> Components: Table API & SQL
> Reporter: Hequn Cheng
> Assignee: Hequn Cheng
> Priority: Major
>
> Flink-8577 implements upsert from stream under proctime. This task is going
> to solve the order problem introduce by proctime. As proposed by Fabian in
> FLINK-8545, it would be good to be able to declare a time attribute that
> decides whether an upsert is performed or not.
> {code:java}
> Table table = tEnv.upsertFromStream(input, 'a, 'b.rowtime.upsertOrder, 'c.key)
> {code}
> This is a good way to solve the order problem using rowtime. And an idea
> comes to my mind that we can even remove the `.upsertOrder`, because the
> rowtime attribute can only be defined once in a table schema. Removing
> `.upsertOrder` also makes it easier to design api for TableSource and sql,
> i.e, we don't need to add another new feature for the api.
> Any suggestions are welcomed!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)