+1 for FLIP-107

Reading different parts of source code should be the key feature for Flink SQL, 
like metadata in CDC data, key and  timestamp in Kafka records.
The scope of FLIP-107 is too big to finish in one version IMO, maybe we can 
start part work in 1.12. 

Best
Leonard

> 在 2020年8月11日,19:51,Kurt Young <ykt...@gmail.com> 写道:
> 
> The content length of FLIP-107 is relatively short but the scope and
> implications it will cause is actually very big.
> From what I can tell now, I think there is a good chance that we can
> deliver part of this FLIP in 1.12, e.g.
> accessing the metadata field just like you mentioned.
> 
> Best,
> Kurt
> 
> 
> On Tue, Aug 11, 2020 at 7:18 PM Dongwon Kim <eastcirc...@gmail.com> wrote:
> 
>> Big +1 for this FLIP.
>> 
>> Recently I'm working on some Kafka topics that have timestamps as
>> metadata, not in the message body. I want to declare a table from the
>> topics with DDL but "rowtime_column_name" in <watermark_definition> seems
>> to accept only existing columns.
>> 
>>> <watermark_definition>:
>>>  WATERMARK FOR rowtime_column_name AS watermark_strategy_expression
>>> 
>>> 
>> I raised an issue in user@ list but committers advise to use alternative
>> approaches that call for detailed knowledge of Flink like custom decoding
>> format or conversion between DataStream API and TableEnvironment. It is
>> definitely against the main advantage of Flink SQL, simplicity and ease of
>> use. This FLIP must be implemented IMHO in order for users to derive tables
>> freely from any Kafka topic without having to involve DataStream API.
>> 
>> Best,
>> 
>> Dongwon
>> 
>> On 2020/03/01 14:30:31, Dawid Wysakowicz <d...@apache.org> wrote:
>>> Hi,>
>>> 
>>> I would like to propose an improvement that would enable reading table>
>>> columns from different parts of source records. Besides the main payload>
>>> majority (if not all of the sources) expose additional information. It>
>>> can be simply a read-only metadata such as offset, ingestion time or a>
>>> read and write  parts of the record that contain data but additionally>
>>> serve different purposes (partitioning, compaction etc.), e.g. key or>
>>> timestamp in Kafka.>
>>> 
>>> We should make it possible to read and write data from all of those>
>>> locations. In this proposal I discuss reading partitioning data, for>
>>> completeness this proposal discusses also the partitioning when writing>
>>> data out.>
>>> 
>>> I am looking forward to your comments.>
>>> 
>>> You can access the FLIP here:>
>>> 
>> 
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-107%3A+Reading+table+columns+from+different+parts+of+source+records?src=contextnavpagetreemode
>>> 
>> 
>>> 
>>> Best,>
>>> 
>>> Dawid>
>>> 
>>> 
>>> 
>> 

Reply via email to