[ 
https://issues.apache.org/jira/browse/FLINK-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flink Jira Bot updated FLINK-3751:
----------------------------------
    Labels: stale-minor  (was: )

> default Operator names are inconsistent
> ---------------------------------------
>
>                 Key: FLINK-3751
>                 URL: https://issues.apache.org/jira/browse/FLINK-3751
>             Project: Flink
>          Issue Type: Bug
>          Components: API / DataSet, API / DataStream
>    Affects Versions: 1.0.1
>            Reporter: Chesnay Schepler
>            Priority: Minor
>              Labels: stale-minor
>
> h3. The Problem
> If a user doesn't name an operator explicitly (generally using the name() 
> method) then Flink auto generates a name. These generated names are really 
> (like, _really_) inconsistent within and across API's.
> In the batch API non-source/-sink operator names are _generally_ formed like 
> this:
> {code}FlatMap (FlatMap at main(WordCount.java:81)){code}
> We have
> * FlatMap, describing the runtime operator type
> * another FlatMap, describing which user-call created this operator
> * main(WordCount.java:81), describing the call location
> This already falls apart when you have a DataSource, which looks like this:
> {code}DataSource (at getDefaultTextLineDataSet(WordCountData.java:70) 
> (org.apache.flink.CollectionInputFormat){code}
> It is missing the call that created the sink (fromElements()) and suddenly 
> includes the inputFormat name.
> Sink are a different story yet again, since collect() is displayed as
> {code} DataSink (collect()) {code}
> which is missing the call location.
> Then we have the Streaming API  where things are named completely different 
> as well:
> The fromElements source is displayed as 
> {code} Source: Collection Source {code}
> non-source/-sink operators are displayed simply as their runtime operator type
> {code} FlatMap {code}
> and sinks, at times, do not have a name at all.
> {code} Sink: Unnamed {code}
> To put the cherry on top, chains are displayed in the Batch API as
> {code} CHAIN <operator> -> <operator> {code}
> while in the Streaming API we lost the CHAIN keyword
> {code} <operator> -> <operator> {code}
> Considering that these names are right in the users face via the Dashboard we 
> should try to homogenize them a bit.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to