* Fixed: values bound with BindEnv added to AllKeys()
Cast was not working, and v.env wasn't used when merging keys.
Rewrote explicit and specific casts for maps storing strings or FlagValues.
* Added: test for BindEnv() and AllKeys()
To make sure AllSettings() and Unmarshal() will consider environment
variables added with BindEnv().
* Fixed: insensitiviseMaps and tests
All keys (even nested ones) are now lower-cased recursively.
On the way, map[interface{}]interface{} are cast to map[string]interface{}
* Changed: simplified find() fast path and increase performance
Removed searchMapForKey(), fast path directly integrated into searchMap() and
searchMapWithPathPrefixes()
=> more generic (searchMapForKey() wasn't called everywhere it should have)
At the same time, significantly speed up searchMap() and searchMapWithPathPrefixes(),
which are still used for nested keys: the assumption that map keys are all
lower-cased allows to perform
val = m[key]
instead of
for k, v := range m {
if strings.ToLower(k) == strings.ToLower(key) {
val = v
}
}
=> i.e., directly access the map instead of enumerate the keys
Fixes#71, #93, #158, #168, #209, #141, #160, #162, #190
* Fixed: indentation in comment
* Fixed: Get() returns nil when nested element not found
* Fixed: insensitiviseMaps() made recursive so that nested keys are lowercased
* Fixed: order of expected<=>actual in assert.Equal() statements
* Fixed: find() looks into "overrides" first
* Fixed: TestBindPFlags() to use a new Viper instance
* Fixed: removed extra aliases from display in Debug()
* Added: test for checking precedence of dot-containing keys.
* Fixed: Set() and SetDefault() insert nested values
* Added: tests for overriding nested values
* Changed: AllKeys() includes all keys / AllSettings() includes overridden nested values
* Added: test for shadowed nested key
* Fixed: properties parsing generates nested maps
* Fixed: Get() and IsSet() work correctly on nested values
* Changed: modifier README.md to reflect changes
Also avoid doing a strings.Split in the Get common case.
Any TRACE statements in these hot paths must be totally turned off when not testing.
```
benchmark old ns/op new ns/op delta
BenchmarkGetBool-4 4090 409 -90.00%
BenchmarkGetBoolFromMap-4 6.33 6.28 -0.79%
benchmark old allocs new allocs delta
BenchmarkGetBool-4 6 3 -50.00%
BenchmarkGetBoolFromMap-4 0 0 +0.00%
benchmark old bytes new bytes delta
BenchmarkGetBool-4 129 33 -74.42%
BenchmarkGetBoolFromMap-4 0 0 +0.00%
```
Fixes#242
* Fix typo in description of UnmarshalExact
* Omit 2nd values from range loops
* Delete findCWD method from util (was unused)
* Edit documentation according to golint
* Fix documentation in util
* Use RemoteProvider interface instead of defaultRemoteProvider
* Fix err variable in BindFlagValues
I stumbled over this when trying to merge multiple configs.
```
viper.SetConfigName("default")
err := viper.MergeInConfig()
```
which caches file path resolvemenet in `v.configFile`
and then
```
viper.SetConfigName("prod")
err := viper.MergeInConfig()
```
which reuses `v.configFile` without updating it accordingly to the new name.
See c1ccc378a0/viper.go (L1240)
This patch adds the `MergeConfig` and `MergeInConfig` functions to
enable reading new configuration files via a merge strategy rather
than replace. For example, take the following as the base YAML for a
configuration:
hello:
pop: 37890
world:
- us
- uk
- fr
- de
Now imagine we want to read the following, new configuration data:
hello:
pop: 45000
universe:
- mw
- ad
fu: bar
Using the standard `ReadConfig` function the value returned by the
nested key `hello.world` would no longer be present after the second
configuration is read. This is because the `ReadConfig` function and
its relatives replace nested structures entirely.
The new `MergeConfig` function would produce the following config
after the second YAML snippet was merged with the first:
hello:
pop: 45000
world:
- us
- uk
- fr
- de
universe:
- mw
- ad
fu: bar
Examples showing how this works can be found in the two unit tests
named `TestMergeConfig` and `TestMergeConfigNoMerge`.
This patch refactors the IsSet function to examine the keys in order
to see if a key is set instead of simply checking if a value is nil.
This change is necessary due to the fact that default values via
flag bindings will result in the old logic always being true for
the IsSet function due to a type's default value such as 0 for an
integer or an empty string for a string. While a type's default
value may be preferable when getting the value for a key, it
results in a false positive when determining if a key is actually
set. This change enables users to detect whether a key is set by
only returning a flag's value if it has changed.
This reverts commit 8d9577a72e.
The commit is reasonable enough, but this is a major breaking change for Hugo.
We have to figure out how to handle this before we introduce this one.
See https://github.com/spf13/hugo/issues/1129
Bjørn Erik Pedersen