> On Nov 21, 2016, at 2:04 PM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > But this is precisely the scenario in mind when the original RecSourceT code > was put in for core. Otherwise, it's not possible to support the use of an > old configuration with the new code. The default values of B and C will take > precedence over value set for A in records.config even if neither B nor C is > mentioned in the actual configuration of ATS. Even you write "Fallback to A > would make sense if B and C are not present" but without this change, you > can't do that.
You can; you use a designated missing value (NULL, -1, etc) as the default. Alternatively, have an explicit foo.is_enabled value (defaulting to disabled), which we do all the time. I think that it is *really* confusing to distinguish between “foo=1” as the default and “foo=1” as “I actually mean it. I can’t even imagine how we would document the behaviour of plugins or configuration settings that take advantage of this. > > On Monday, November 21, 2016 3:37 PM, James Peach <jpe...@apache.org> > wrote: > > > >> On Nov 21, 2016, at 1:22 PM, Alan Carroll >> <solidwallofc...@yahoo-inc.com.INVALID> wrote: >> >> The use case is providing backwards compatibility. Suppose a plugin uses >> config value A. A newer version, in order to support additional features, >> uses values B and C. It would be nice to be able to detect that neither B >> nor C were explicitly set by the administrator in records.config and >> therefore the plugin should fall back and use A. It is also required to >> *not* fall back to A if the administrator explicitly set B or C to the >> default value. Therefore checking the retrieved value against the default >> value is insufficient. One might use a bogus default value then, but now >> there's a problem if none of A,B, or C was set. > > I don’t think this is sane :) > > There’s no effective difference between a default value and a configured > value. Mentioning a configuration value in `records.config` doesn’t mean > “really make this so”, it just sets that value. So the newer plugin should > just use B and C. Fallback to A would make sense if B and C are not present > (eg. the value is a NULL string or some designared int), but this is specific > to the plugin and unrelated to where the configuration value was set. Ad > default is just as legitimate as an explicit configuration. > > "It is also required to *not* fall back to A if the administrator explicitly > set B or C to the default value” > > This requirement leads to extremely confusing behavior and IMHO it is best to > not go there.
