flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fhueske <...@git.apache.org>
Subject [GitHub] flink pull request #3829: [FLINK-6442] [table] Extend TableAPI Support Sink ...
Date Mon, 04 Sep 2017 16:14:23 GMT
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 ?


---

Mime
View raw message