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
enabl
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.
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
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
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 co
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
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 t
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 re
