You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if I doing it wrongly or misunderstand the source code, the with_list_parse_key option is creating a map that will be used to check if a field should use list parser. In the case of vector of struct that contains vector field it is not possible to specify the key unless we specify all the possible index.
structNested{pubkeys:Vec<String>,}structConfig{pubnested:Vec<Nested>}let env_source = Environment::with_prefix("server_config").list_separator(",")// note: need to list all the possible index.with_list_parse_key("nested[0].keys").with_list_parse_key("nested[1].keys").try_parsing(true);
Is this the expected behaviour or could it be possible to support key like nested[*].keys?
The text was updated successfully, but these errors were encountered:
Currently, we only have one path syntax. The question would be whether we should only support wildcards here or if we could make it work to support wildcards in most places that take a path (and error otherwise). Should we also support this for keys?
I would lean towards general wildcard support. My maintenance of this crate is more passive, so someone wanting to see this done will need to take an active hand in investigating this and proposing a design (e.g. where all does path syntax apply, whether it makes sense to take a wildcard, what the behavior would be, the feasibility of meeting that behavior).
Not sure if I doing it wrongly or misunderstand the source code, the
with_list_parse_key
option is creating a map that will be used to check if a field should use list parser. In the case of vector of struct that contains vector field it is not possible to specify the key unless we specify all the possible index.Is this the expected behaviour or could it be possible to support key like
nested[*].keys
?The text was updated successfully, but these errors were encountered: