beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Cwik (JIRA)" <j...@apache.org>
Subject [jira] [Created] (BEAM-2261) Add the ability to override values set with @Default.YYY on PipelineOptions
Date Thu, 11 May 2017 16:31:04 GMT
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)

Mime
View raw message