XComp commented on code in PR #24390:
URL: https://github.com/apache/flink/pull/24390#discussion_r1507288792
##########
flink-connectors/flink-connector-files/src/test/java/org/apache/flink/connector/file/table/FileSystemOutputFormatTest.java:
##########
@@ -104,15 +113,101 @@ void testNonPartition() throws Exception {
.containsExactly("a1,1,p1\n" + "a2,2,p1\n" + "a2,2,p2\n" +
"a3,3,p1\n");
}
+ @ParameterizedTest
+ @ValueSource(booleans = {true, false})
+ void testStagingDirBehavior(boolean shareStagingDir) throws Exception {
Review Comment:
I guess we're getting closer here. :-) I'm not that familiar with this part
of the code. But as said earlier, a complicated verbose unit test is an
indication for a non-optimal code structure. Also checking the interfaces'
JavaDocs backs your proposal:
For `DynamicTableSink` (which is what `FileSystemTableSink` implements):
> Sink of a dynamic table to an external storage system.
For `OutputFormat` (which is what `FileSystemOutputFormat` implements):
> The base interface for outputs that consumes records. The output format
describes how to store the final records, for example in a file.
The key sentence here is `The output format describes how to store the final
records, for example in a file.`. The "how" should include the "where", i.e.
the `OutputFormat` implementation should be in charge of creating the staging
folder and, therefore, would be also in charge of create a folder that is not
used by any other `OutputFormat` instance.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
