Github user fhueske commented on a diff in the pull request:

    https://github.com/apache/flink/pull/3829#discussion_r136850229
  
    --- Diff: 
flink-libraries/flink-table/src/main/scala/org/apache/flink/table/api/BatchTableEnvironment.scala
 ---
    @@ -106,6 +106,43 @@ abstract class BatchTableEnvironment(
       }
     
       /**
    +    * Registers an external [[TableSink]] in this [[TableEnvironment]]'s 
catalog.
    +    * Registered sink tables can be referenced in SQL DML clause.
    +    *
    +    * Examples:
    +    *
    +    * - predefine a table sink with schema
    --- End diff --
    
    I proposed this API for the following reason:
    
    I would like to have a common API and preconditions for pre-registered and 
on-demand used table sinks such that all (also existing) table sinks can be 
used in both of these use cases. 
    
    There is already the `configure()` method which has exactly the purpose of 
setting the field names and types. Currently, this method is only internally 
called during the translation process. Of course, users could implement a 
`TableSink` by setting field names and types in the constructor (as shown in 
the Scala docs of this PR), but I think this would kind of circumvent the 
current API and might lead to `TableSink` implementations that can be either 
used in a pre-registered or an on-demand setting. Hence, I think it would be 
better to "enforce" the use of the `configure()` method by designing the API 
such that the `configure()` method is always internally called and hence 
mandatory. That way we can guarantee that each `TableSink` can be used in both 
cases because both use case require `configure()` and use it in the same way.
    
    We could ask users to call the `configure()` method before registering the 
table sink with an error message (as @wuchong proposed) or enforce this through 
the API. I think the second approach is better because users would not 
experience an exception. In my opinion, we should at least "encourage" the use 
of the `configure()` method by not giving an example that sets field names and 
types in the constructor.
    
    What do you think @lincoln-lil and @wuchong ?


---

Reply via email to