On 15.09.20 06:05, Guowei Ma wrote:
## Using checkpointId In the batch execution mode there would be no normal checkpoint any more. That is why we do not introduce the checkpoint id in the API. So it is a great thing that sink decouples its implementation from checkpointid. :)
Yes, this is a very important point of the design! On 15.09.20 06:28, Guowei Ma wrote:
I am open to alternative 1. Maybe I miss something but I do not get why the second alternative would depend on `flink-runtime` or `flink-streaming-java`. The all the state api currently is in the flink-core. Could you give some further explanation? thanks :)
You're right, yes. It seems I was thinking about other things. I also prefer alternative 1 because it's more "declarative", i.e. the sink has a fixed method where it can return something. Instead of the framework giving an interface to the sink that it can then use in arbitrary ways. Alternative 1 leaves more freedom to the framework but limits the sink. Alternative 2 leaves more freedom to the sink but limits the framework, potentially.
Best, Aljoscha
