Binding flags and unmarshalling to nested structures

[benoitmasson]

Hi,

I've run into a small issue when overriding a configuration value with a command-line flag: after unmarshalling to a struct, fields in nested sub-structures are not updated, while level-1 fields are.

For example, this piece of code:

type Config struct {
    Test1  int
    Nested struct {
        Test2 int
    }
}

func main() {
    var cfg Config

    // init flags and bind to viper
    flag.Int("test1", 0, "Test1")
    flag.Int("nested.test2", 0, "Nested test2")
    flag.Parse()
    viper.BindPFlag("test1", flag.Lookup("test1"))
    viper.BindPFlag("nested.test2", flag.Lookup("nested.test2"))

    // read config
    viper.SetConfigName("config")
    viper.AddConfigPath(".")
    err := viper.ReadInConfig()
    if err != nil {
        panic(err)
    }
    err = viper.Unmarshal(&cfg)
    if err != nil {
        panic(err)
    }

    // run
    fmt.Println(viper.GetInt("test1"), viper.GetInt("nested.test2"))
    fmt.Println(cfg.Test1, cfg.Nested.Test2)
}

associated with this configuration file:

test1 = 11

[nested]
test2 = 12

produces the following output:

> ./main
11 12
11 12
> ./main --test1=21 --nested.test2=22
21 22
21 12

The last nested.test2 value is correct when using viper.GetInt("nested.test2"), but it is not in the struct, while both values are correct for test1.

This may be related to Issue #168, where it also appears that the nested struct is not updated when the internal map changes.

[benoitmasson]

PR #195 should have fixed this issue.

[sm3142]

I'm not sure what is actually happening is what you hope for. If you dump out the resulting config with AllSettings(), you see that the binding has actually created an extra top level item:

map[nested:map[test2:12] test1:21 nested.test2:22]

viper.GetInt("nested.test2") will actually fetch the top level item, not the nested one. The last example in Accessing Nested Keys of the Viper documentation explains why this is so:

Lastly, if there exists a key that matches the delimited key path, its value will be returned instead.

PS: Yep, I just spent some ungodly amount of time trying to bind nested objects too. Apparently it is not supported.

edit: Just saw that PR #195 hasn't been merged to master yet. So there is still hope :)

[benoitmasson]

Indeed, the current version of AllSettings() does not consider flag names with dot separator as “nested” keys.

That's the purpose of commit d8a62ff in PR #195, it fixed the issue for me. Feel free to use the modified code until it is merged.

[sm3142]

@benoitmasson: Actually did pull your patch, works beautifully for me as well. Thanks a bundle!

[awfm9]

Fixed by #195

[sjames-iberis]

Is there still a similar issue with use of UnmarhsalKey?
For example, if I add the following to the original code above:

err = viper.UnmarhsalKey("nested", &cfg.Nested)
fmt.Println(cfg.Nested.Test2)

It always produces the value from the config file; the command line override never takes effect.

./main --test1=21 --nested.test2=22
21 22
21 22
12

[tunhuit]

I have the same issue. The command line don't override the value. The struct always use config file value instead of command line.