[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/2298 Agreed @twalthr. IMO, +1 to merge --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/2298 I think adding some comments the methods doesn't hurt. I would merge this PR as it is. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/2298 Do we agree to stick with the current implementation? If yes, let's close this PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user fhueske commented on the issue: https://github.com/apache/flink/pull/2298 +1 for sticking to Java DataSet / DataStream for the reasons @twalthr gave. The methods should be tagged with the `@Internal` annotation when we add them to the Table API. I would not rename `TableSource` to `TableInputFormat` because 1) it has no relationship to the `InputFormat` interface and 2) there is already a `TableInputFormat` for HBase tables (name is not very fortunate though...). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/2298 @StephanEwen A user can also call `CsvInputFormat.nextRecord()` because it is public, but this was never a problem. If we want to restrict visibility of `TableSource` interface methods, we have to convert the interfaces to classes and provide 3 class for batch, stream, batch&stream. Also not very nice. In general, the Scala classes hide the Java API streams and environments within the Table API. But in this case the user wants to implement a custom TableSource and since the Table API is internally using the Java API I think it is ok, if Java API and not Scala API is used for that. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/2298 Would be great to reflect the "do not use" with proper visibility. A JavaDoc comment is usually not helping at all. Also, the dependency on the java API classes in the Scala classes does not seem right. Usually the Scala classes hide the Java API streams and environments. Both of these things are usually strong indicators that there are some abstraction issues. Would be good to get that right, while the API is fresh and malleable. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user twalthr commented on the issue: https://github.com/apache/flink/pull/2298 Yes, good idea. We can not restrict it as it is defined in an interface. If we would make it `protected`, we could not call it from the outside. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] flink issue #2298: [FLINK-4247] [table] CsvTableSource.getDataSet() expects ...
Github user zentol commented on the issue: https://github.com/apache/flink/pull/2298 +1. We could also use the `@Internal` annotations for this. Out of curiosity, could you explain we can't just restrict access to the methods? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
