Loading a YAML file makes all keys lowercase, but YAML keys are case sensitive.

[barsanuphe]

Since the recent changes, all keys have become lowercase.
If I'm not mistaken (see this reply from YAML spec author), YAML keys are case sensitive.
For instance, calling GetStringMapStringSlice() while loading a YAML file makes all of the keys of the resulting map lowercase, which is unexpected and was not the previous behavior.

[bep]

GetStringMapStringSlice() while loading a YAML file

When do you call that method while loading a YAML file?

[barsanuphe]

If you have:

yaml_key:
         Case Sensitive Key: 
               - value1
               - value2

GetStringMapStringSlice("yaml_key") now gives a map with a case sensitive key key.

[bep]

To conclude: Viper have always tried to be case-insensitive by doing a lower-casing of the keys given. It was however not being doing that deeply for maps. Now that is fixed and we are seeing some breakage in the wild.

The main problem seems to be the expectation that you should be able to unmarshal the config map into a struct or similar.

Because for plain lookups, like viper.Get("a.b.A.d."), this is clearly an improvement.

@spf13 should chime in here.

[bep]

GetStringMapStringSlice("yaml_key") now gives a map with a "case sensitive key" key.

No, it gives a lower-cased key.

[barsanuphe]

No, it gives a lower-cased key.

Yes, I meant it gives the value: case sensitive key in my example.

I understand your point of view that this is the intended behavior, but I find it surprising for YAML. And I'm not expecting to unmarshall the config map into anything, I'm happy dealing with a map[string][]string. I was just relying on the keys to have the same case I put in the YAML file.

My "top" keys are lowercase though, so I didn't realize viper was already returning lowercased versions for anything but maps.

[bep]

I understand your situation -- I have a similar breakage in one of my apps. We should probably have handled this in a better way, but I believe it is the intended behavior of Viper from the start. @spf13 should decide.

[spf13]

The way I think it should work is a bit of a hybrid of case sensitivity.

Keys should be treated as case insensitive when getting, setting or
merging. I can't see another approach that would make sense here.

Returning keys would ideally be in the case originally defined.

The challenge here is that while yaml is case sensitive, not all of the
configuration options are (flags, env vars, etc). Even Go itself has odd
sensitivity behaviors as the initial letter is loaded with exportability.

On Fri, Oct 14, 2016 at 7:06 PM Bjørn Erik Pedersen <
notifications@github.com> wrote:

I understand your situation -- I have a similar breakage in one of my
apps. We should probably have handled this in a better way, but I believe
it is the intended behavior of Viper from the start. @spf13
https://github.com/spf13 should decide.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#260 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKlZFU7xGn_CZg1KReWeJ9rlKudEy1nks5q0ArYgaJpZM4KXgSN
.

[bep]

Returning keys would ideally be in the case originally defined.

Which is a very expensive requirement, and in many cases not possible.

As I said earlier, this change was pushed earlier but then I did a revert. Viper is getting pretty complex -- it would be nice to have a simple and agreeable understanding of the casing of strings.

[awfm9]

I am not familiar with many configuration use cases and the requirements for case sensitive keys, but if I can chime in, I really think the consistent conversion to lower case keys is the way to go. Feel free to point out some cases that I have no vision on, but I don't really see an upside to complicating the code with some hybrid handling.

[bep]

I agree with @awishformore -- I suggest we just ride off the storm.

[dgoeke]

I am not familiar with many configuration use cases and the requirements for case sensitive keys

Our application uses viper for describing environment variables in a YAML file:

environment:
  FIRST_THING: yes
  secondThing: no

These could have arbitrary names/values since the user defines them. But environment variables are case sensitive, so this means we can no longer represent them naturally as a map. I suppose we will have to switch to something like a list of key=value if we want to continue using viper.

[gabdelab]

Hi, to follow up on this issue, I encountered a bug with my configuration, with some Keys in lists and some other unlisted:

package main

import (
	"bytes"
	"fmt"
	"github.com/spf13/viper"
)

var yamlExample = []byte(`
Unlisted:
    Test: true
Listed:
    - Test: true
`)

func main() {
	viper.SetConfigType("yaml")
	viper.ReadConfig(bytes.NewBuffer(yamlExample))

	// Will output "test:true"
	var a interface{}
	viper.UnmarshalKey("Unlisted", &a)
	fmt.Println(a)

	// Will output "Test:true"
	var b interface{}
	viper.UnmarshalKey("Listed", &b)
	fmt.Println(b)
}

Shouldn't all keys be treated the same way ? These two different behaviors look quite error-prone to me.

[wminjay]

It seems to be intentional

func insensitiviseMap(m map[string]interface{}) {
	for key, val := range m {
		switch val.(type) {
		case map[interface{}]interface{}:
			// nested map: cast and recursively insensitivise
			val = cast.ToStringMap(val)
			insensitiviseMap(val.(map[string]interface{}))
		case map[string]interface{}:
			// nested map: recursively insensitivise
			insensitiviseMap(val.(map[string]interface{}))
		}

		lower := strings.ToLower(key)
		if key != lower {
			// remove old key (not lower-cased)
			delete(m, key)
		}
		// update map
		m[lower] = val
	}
}