You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Luke Cwik (JIRA)" <ji...@apache.org> on 2017/05/11 16:31:04 UTC
[jira] [Created] (BEAM-2261) Add the ability to override values set
with @Default.YYY on PipelineOptions
Luke Cwik created BEAM-2261:
-------------------------------
Summary: Add the ability to override values set with @Default.YYY on PipelineOptions
Key: BEAM-2261
URL: https://issues.apache.org/jira/browse/BEAM-2261
Project: Beam
Issue Type: Improvement
Components: sdk-java-core
Reporter: Luke Cwik
Priority: Minor
Users may want to set a value only if the value isn't the default.
When a user calls *PipelineOptionsFactory.fromArgs(args).as(Options.class)* they cannot tell if a user set the value from the command-line or whether the value is a default that was generated through the usage of the *@Default.YYY* annotations.
There is currently no method to introspect whether a default is set and we could:
* add a *isOptionSet()* method, but this adds many methods to the interfaces
* ask whether something is the default or set by name or by method reference, *options.isSet("options" / method)*, but is brittle to any name changes in options.
* allowing users to override with another interface defining a new *@Default.YYY* is difficult because:
** multiple inheritance makes choosing a default difficult:
{code}
MyPipelineOptions extends OptionsA, OptionsB { }
OptionsA {
@Default.String("A")
String getString();
}
OptionsB {
@Default.String("B")
String getString();
}
{code}
** even if the was little ambiguity initially with MyPipelineOptions defined as:
{code}
MyPipelineOptions extends OptionsA, OptionsB {
@Default.String("C")
String getString();
}
{code}
defaults are resolved lazily on first access and it would be strange if the default resolved depending on the order of "as" calls.
{code}
options.as(MyPipelineOptions.class).getString()
options.as(OptionsA.class).getString()
options.as(OptionsB.class).getString()
would all provide different answers.
{code}
Finally that leaves us with an option to add support for merging PipelineOptions (as long as they are compatible).
{code}
PipelineOptions PipelineOptionsFactory.merge(PipelineOptions ... options)
{code}
where all subsequent options overwrite any prior set options and the empty array returning the default *PipelineOptionsFactory.create()*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)