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.
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.
