[
https://issues.apache.org/jira/browse/BEAM-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16898260#comment-16898260
]
Maximilian Michels commented on BEAM-7850:
------------------------------------------
Thanks for expanding on this. After taking a closer look, it makes perfect
sense to move Environment to the top-level PTransform message because all other
transforms are derived from this base message.
You mentioned WindowStrategy and SideInput still using SdkFunctionSpec with
Environment. There is also the Coder message. If I'm not mistaken, we could
remove the environment from SdkFunctionSpec entirely because all these messages
should be implicitly bound to an environment from the PTransform. Perhaps
somebody else could comment on whether this would be feasible? I can't think of
a situation where this is not the case.
+1 Definitely seems like a sensible change.
> Make Environment a top level attribute of PTransform
> ----------------------------------------------------
>
> Key: BEAM-7850
> URL: https://issues.apache.org/jira/browse/BEAM-7850
> Project: Beam
> Issue Type: Improvement
> Components: beam-model
> Reporter: Chamikara Jayalath
> Priority: Major
>
> Currently Environment is not a top level attribute of the PTransform (of
> runner API proto).
> [https://github.com/apache/beam/blob/master/model/pipeline/src/main/proto/beam_runner_api.proto#L99]
> Instead it is hidden inside various payload objects. For example, for ParDo,
> environment will be inside SdkFunctionSpec of ParDoPayload.
> [https://github.com/apache/beam/blob/master/model/pipeline/src/main/proto/beam_runner_api.proto#L99]
>
> This makes tracking environment of different types of PTransforms harder and
> we have to fork code (on the type of PTransform) to extract the Environment
> where the PTransform should be executed. It will probably be simpler to just
> make Environment a top level attribute of PTransform.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
