[ https://issues.apache.org/jira/browse/BEAM-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592313#comment-15592313 ]
ASF GitHub Bot commented on BEAM-551: ------------------------------------- GitHub user sammcveety opened a pull request: https://github.com/apache/incubator-beam/pull/1146 [BEAM-551] Add NestedValueProvider Wrote this up based on some nascent thoughts, and looking ahead to PubsubIO, which uses a bunch of wrapper classes instead of String. This allows us to nicely turn those into VP<WrapperClass> instead of deferring all the translation code into the caller, which would be gross. R: @dhalperi You can merge this pull request into a Git repository by running: $ git pull https://github.com/sammcveety/incubator-beam sgmc/nested_vp Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-beam/pull/1146.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 #1146 ---- commit e06fd8ce238971d1b235ce01f527f7cedb058127 Author: sammcveety <sam.mcve...@gmail.com> Date: 2016-10-20T16:29:04Z Add NestedValueProvider ---- > Support Dynamic PipelineOptions > ------------------------------- > > Key: BEAM-551 > URL: https://issues.apache.org/jira/browse/BEAM-551 > Project: Beam > Issue Type: New Feature > Components: beam-model > Reporter: Sam McVeety > Assignee: Frances Perry > Priority: Minor > > During the graph construction phase, the given SDK generates an initial > execution graph for the program. At execution time, this graph is > executed, either locally or by a service. Currently, Beam only supports > parameterization at graph construction time. Both Flink and Spark supply > functionality that allows a pre-compiled job to be run without SDK > interaction with updated runtime parameters. > In its current incarnation, Dataflow can read values of PipelineOptions at > job submission time, but this requires the presence of an SDK to properly > encode these values into the job. We would like to build a common layer > into the Beam model so that these dynamic options can be properly provided > to jobs. > Please see > https://docs.google.com/document/d/1I-iIgWDYasb7ZmXbGBHdok_IK1r1YAJ90JG5Fz0_28o/edit > for the high-level model, and > https://docs.google.com/document/d/17I7HeNQmiIfOJi0aI70tgGMMkOSgGi8ZUH-MOnFatZ8/edit > for > the specific API proposal. -- This message was sent by Atlassian JIRA (v6.3.4#6332)