Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/5977#discussion_r188725700
--- Diff:
flink-core/src/main/java/org/apache/flink/api/common/functions/RuntimeContext.java
---
@@ -71,6 +71,17 @@
@PublicEvolving
MetricGroup getMetricGroup();
+ /**
+ * Returned value is guaranteed to be unique between operators within
the same job and to be
+ * stable and the same across job submissions.
+ *
+ * <p>This operation is currently only supported in Streaming
(DataStream) contexts.
+ *
+ * @return String representation of the operator's unique id.
+ */
+ @PublicEvolving
+ String getOperatorUniqueID();
--- End diff --
I am still much in favor of not exposing this in the RuntimeContext:
- Having the state accesses in the RuntimeContext was a necessity of that
moment, because there was no `initializeState()` and it is crucial to be
exposed to users.
- This operatorID is not crucial to be exposed to users, hence a very
different case to me.
- It is super easy to expose it later, it is much harder (even if marked
as PublicEvolving) to hide it later. For a quick move, not exposing an addition
publicly should always be the default choice, also beyond this specific case
here.
---
