* Function AllKeys() now returns all keys holding a value (for nested values,
the nested key is the full path, i.e., a sequence of dot-separated keys).
Previously, returned only depth-1 keys, as well as flags and environment
variables: this is more generic and may be used widely.
Besides, it takes into account shadowed keys (key ignored if shadowed by
a path at a higher-priority level).
* Function AllSettings() now returns nested maps for all keys holding a value,
as specified by AllKeys().
The value stored in the map is the one with highest priority, as returned
by the Get() function (taking into account aliases, environment variables,
flags, etc.).
This fixes Unmarshal(): it fills in correct values for nested configuration
elements overridden by flags or env variables.
+ tests fixed accordingly
+ test added to TestShadowedNestedValue(), to test Unmarshalling of shadowed keys
Rewriting of find(), which now checks for in-depth values,
and ignores shadowed ones.
* When looking for "foo.bar":
- before: if "foo" was defined in some map, "foo.*" was looked for
only in this map
- now: "foo.*" is looked for in all maps, the first one with a value is
used (even if "foo" was defined elsewhere, in a higher-priority map).
* Also, find() tests that the requested key is not shadowed somewhere
on its path.
e.g., {"foo.bar": 1} in the config map shadows "foo.bar.baz" in
the defaults map
* Lastly, if in the config map, config["foo"]["bar"] and config["foo.bar"]
coexist, the latter value is used.
(this should not be necessary for other maps, since by construction
their keys should not contain dots)
=> Get() and IsSet() corrected and simplified, since all the logic
about value retrieval has been put in find()
+ README.md modified accordingly:
In Section “Accessing nested keys”, to reflect the corrected behavior of find():
- paths searched for at all levels, not only the one of the first sub-key;
- paths may be shadowed by a shorter, higher priority, path.
+ tests modified accordingly
If a property name contains a ".", it is split and generates sub-maps in
the "config" map, as for the other configuration sources.
Tests updated accordingly, to reflect these nested values.
Set() and SetDefault() fixed, so that they insert (or substitute) correctly
"nested values" (= values identified by a complete path, i.e. containing dots;
e.g. "foo.bar").
They scan (and create if needed) intermediate maps, so that the value reaches
the innermost map.
Examples :
* v.override = make(map[string]interface{})
v.Set("foo.bar", 10)
v.Set("foo.baz", 20)
fmt.Println(v.override["foo"]["bar"]) // displays "10"
fmt.Println(v.override["foo"]["baz"]) // displays "20"
Furthermore, pre-existing non-map value are erased:
* v.Set("foo.bar", 10)
v.Set("foo.bar.baz", 20)
fmt.Println(v.override["foo"]["bar"]) // displays "map["baz": 20]"
The low-level work is performed by function deepSearch(), it scans the given
map according to a given key path, creating intermediate maps if necessary.
In function TestNestedOverrides(), in file overrides_test.go
More involved complement to TestOverrides() in viper_test.go,
as suggested in Issue #168 (https://github.com/spf13/viper/issues/168)
"clothing.jacket.price" exists in defaults map, but "clothing.jacket" exists
and is a value in config map
=> should remain undefined (“shadowed” by the config)
overrides (elements added with Set()) should have highest priority,
checked first (was after PFlags).
From README.md:
> Viper uses the following precedence order. Each item takes precedence
> over the item below it:
> • explicit call to Set
> • flag
> • env
> • config
> • key/value store
> • default
+ fix TestBindPFlags() to use a new Viper instance (otherwise, "port" was
defined in an earlier test function with Set() and took precedence)
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
This patch updates the package used for parsing TOML content from
"github.com/BurntSushi/toml" to "github.com/pelletier/go-toml" as the
latter uses a more accepted OSS license (MIT), enabling the inclusion of
Viper or projects that depend on Viper in projects that have licensing
requirements incongruent with the license of the previous TOML package.
Closes#228Closes#225Fixes#179
Since Hugo is such a heavy user of Viper, this patch adds an
after_success section to the Travis-CI build that validates the Viper
commit by attempting to build Hugo and executing `hugo -s docs`.
This patch handles issue #222.
It breaks Hugo, will have to test/investigate.
Erro when building Hugo docs:
```
ERROR: 2016/08/05 11:19:23 site.go:1208: unable to process menus in site config
ERROR: 2016/08/05 11:19:23 site.go:1209: Unable to Cast map[string]interface {}{"pre":"<i class='fa fa-space-shuttle'></i>", "weight":-20, "url":"/commands/", "name":"Hugo Cmd Reference", "identifier":"commands"} of type map[string]interface {} to []interface{}
```
This reverts commit 7402856f06.
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 updates the package used for parsing TOML content from
"github.com/BurntSushi/toml" to "github.com/pelletier/go-toml" as the
latter uses a more accepted OSS license (MIT), enabling the inclusion of
Viper or projects that depend on Viper in projects that have licensing
requirements incongruent with the license of the previous TOML package.
This patch replaces the PR https://github.com/spf13/viper/pull/208 after
discussing the matter with @spf13 and deciding to update the TOML parser
instead of making TOML build-optional.
Then checking the file name in the event handler. This seems to be the only robust way
of handling changes from a single file on multiple platforms and editors.
See #142
* Only add *the* config file, not all possible folders
* Trigger reload on both write and create events;
the latter is what we get from atomic save editors (like TextMate) once https://github.com/go-fsnotify/fsnotify/pull/111 is merged
See #142
This patch fixes a bug with how Viper handle's key casing when keys are
nested. While Viper is generally case-insensitive, this was not the case
with regards to nested keys. This patch makes nested keys insensitive as
well.
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`.
