luoyuxia commented on code in PR #21676:
URL: https://github.com/apache/flink/pull/21676#discussion_r1071030668
##########
flink-table/flink-table-api-java/src/main/java/org/apache/flink/table/api/internal/TableEnvironmentImpl.java:
##########
@@ -1400,6 +1411,23 @@ public TableResultInternal executeInternal(Operation
operation) {
} catch (Exception e) {
throw new TableException("Failed to execute ANALYZE TABLE
command", e);
}
+ } else if (operation instanceof DeleteFromFilterOperation) {
+ if (isStreamingMode) {
+ throw new TableException("DELETE TABLE is not supported for
streaming mode now.");
+ }
+ Optional<Long> rows =
Review Comment:
Thanks for attention.
Yes, it's acceptable.
1: When the predicate contain subquery, the delete can't be pushed, it can
fall back to SupportsRowLevelDelete which support to delete for all cases.
2: Still, only delete can pushed to table source, will we do the deletion in
here. If the delete can be pushed down, it's be more like it's to drop some
partition/delete files for storage based on files. I think it's similar to
drop partition which is also done in TableEnvironmentImpl. For other storage
like mysql, it expect to delegate the delete stamement to the underlying
engine, I think it's fine that client should have the ability to connect to
the underlying engine.
Also, I think it's beneficial that execute it in client direclty which we
also reduce the cost of generate/deploy job.
For more detail, you can refer to the
[FLIP-282](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235838061)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
