kennknowles commented on a change in pull request #14155:
URL: https://github.com/apache/beam/pull/14155#discussion_r596241162
##########
File path: sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/DoFn.java
##########
@@ -91,6 +91,16 @@
*/
public abstract class DoFn<InputT extends @Nullable Object, OutputT extends
@Nullable Object>
implements Serializable, HasDisplayData {
+ /** Information accessible while within the {@link Setup} method. */
+ @SuppressWarnings("ClassCanBeStatic") // Converting class to static is an
API change.
+ public abstract class SetupContext {
Review comment:
Yes, this feature of "context" objects is double edged: it is very hard
to know what is actually in the context, or used.
Very concretely: we want to be able to analyze the `DoFn` to figure out the
signature. Like if it does not actually ask for `PipelineOptions` we may not
have to plumb them. Or for runners that do not keep them at runtime we could
reject the pipeline, etc. For state and timers, we could know if it was a
stateful DoFn and also validate the tags. It also made side inputs have less
boilerplate and be parameters instead of fixed values at DoFn construction, etc.
We still have `ProcessContext` mostly for just legacy backwards
compatibility but if people really want to use it they can. But in this case
for `SetupContext` it has just one thing in it so there isn't really a need. It
just adds indirection where you don't need it.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
