[
https://issues.apache.org/jira/browse/BEAM-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937655#comment-15937655
]
ASF GitHub Bot commented on BEAM-115:
-------------------------------------
GitHub user kennknowles opened a pull request:
https://github.com/apache/beam/pull/2299
[BEAM-115] Make distinguished URNs public
These URNs are in flux and will be relocated to some final good location as
the
Runner API and Fn API develop. For now, this change just makes them public
in
the place where they currently are defined.
R: @tgroh
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kennknowles/beam custom-windowfn
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/beam/pull/2299.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2299
----
commit 94814e88f6d6737f389c7b8e8727d3a4a78bba54
Author: Kenneth Knowles <[email protected]>
Date: 2017-03-23T03:33:24Z
Make distinguished URNs public
These URNs are in flux and will be relocated to some final good location as
the
Runner API and Fn API develop. For now, this change just makes them public
in
the place where they currently are defined.
----
> Beam Runner API
> ---------------
>
> Key: BEAM-115
> URL: https://issues.apache.org/jira/browse/BEAM-115
> Project: Beam
> Issue Type: Improvement
> Components: beam-model-runner-api
> Reporter: Kenneth Knowles
> Assignee: Kenneth Knowles
>
> The PipelineRunner API from the SDK is not ideal for the Beam technical
> vision.
> It has technical limitations:
> - The user's DAG (even including library expansions) is never explicitly
> represented, so it cannot be analyzed except incrementally, and cannot
> necessarily be reconstructed (for example, to display it!).
> - The flattened DAG of just primitive transforms isn't well-suited for
> display or transform override.
> - The TransformHierarchy isn't well-suited for optimizations.
> - The user must realistically pre-commit to a runner, and its configuration
> (batch vs streaming) prior to graph construction, since the runner will be
> modifying the graph as it is built.
> - It is fairly language- and SDK-specific.
> It has usability issues (these are not from intuition, but derived from
> actual cases of failure to use according to the design)
> - The interleaving of apply() methods in PTransform/Pipeline/PipelineRunner
> is confusing.
> - The TransformHierarchy, accessible only via visitor traversals, is
> cumbersome.
> - The staging of construction-time vs run-time is not always obvious.
> These are just examples. This ticket tracks designing, coming to consensus,
> and building an API that more simply and directly supports the technical
> vision.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
