Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CaseSensitiveKeys option #1673

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

travisnewhouse
Copy link

Case-sensitive keys are one of the most request features of Viper. See #1014.

When reading configuration from sources with case-sensitive keys, such as YAML, TOML, and JSON, a user may wish to preserve the case of keys that appear in maps. For example, consider when the value of a setting is an (opaque) map with string keys that are case-sensitive. Ideally, if the map value is not going to be indexed by a Viper lookup key, then the map value should be treated as an opaque value by Viper, and its keys should not be modified.

Viper's default behavior is that keys are case-sensitive, and this behavior is implemented by converting all keys to lower-case. For users that wish to preserve the case of keys, this commit introduces an Option CaseSensitiveKeys() that can be used to configure Viper to use case-sensitive keys. When CaseSensitiveKeys is enabled, all keys retain the original case, and lookups become case-sensitive (except for lookups of values bound to environment variables).

The behavior of Viper could become hard to understand if a user could change the CaseSensitiveKeys setting after values have been stored. For this reason, the setting may only be set when creating a Viper instance, and it cannot be set on the "global" Viper. This merge request implements case-sensitive keys in a manner that respects the existing behavior of the "global" Viper, and gives users an option to create a Viper that uses case-sensitive keys behavior.

When reading configuration from sources with case-sensitive keys,
such as YAML, TOML, and JSON, a user may wish to preserve the case
of keys that appear in maps.  For example, consider when the value
of a setting is a map with string keys that are case-sensitive.
Ideally, if the value is not going to be indexed by a Viper lookup
key, then the map value should be treated as an opaque value by
Viper, and its keys should not be modified.  See spf13#1014

Viper's default behaviour is that keys are case-sensitive, and this
behavior is implemented by converting all keys to lower-case.  For
users that wish to preserve the case of keys, this commit introduces
an Option `CaseSensitiveKeys()` that can be used to configure Viper
to use case-sensitive keys.  When CaseSensitiveKeys is enabled, all
keys retain the original case, and lookups become case-sensitive
(except for lookups of values bound to environment variables).

The behavior of Viper could become hard to understand if a user
could change the CaseSensitiveKeys setting after values have been
stored.  For this reason, the setting may only be set when creating
a Viper instance, and it cannot be set on the "global" Viper.
@CLAassistant
Copy link

CLAassistant commented Oct 31, 2023

CLA assistant check
All committers have signed the CLA.

Copy link

👋 Thanks for contributing to Viper! You are awesome! 🎉

A maintainer will take a look at your pull request shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants