winding-lines commented on PR #3429: URL: https://github.com/apache/arrow-rs/pull/3429#issuecomment-1369770538
The comments above have hit the problem on the head:- we want a set of key-values- the keys should not be strings, they should be compiler checkedThe fields inside the builders are close to what we need. I agree that having builders themselves as the API is unusual. But creating a separate layer that has to be kept up to date is also wasteful.A simple refactoring may help here where the actual fields inside the builder structs can be separated and the builder can have a with_config() method. It is would help me a lot of those configs are Clone and serde *.Then we can come up with some macros to read the values from the env.At the endof the day as an user I prefer to not have to type strings.Marius---On Jan 3, 2023, at 3:33 AM, Raphael Taylor-Davies ***@***.***> wrote: Is there perhaps some subset of the options we could expose, perhaps the same subset as exposed by from_env that allow for configuration based on "well-known-keys" that may also be in the environment. key-value-like configs There appears to be consensus on this being the path forward, having an explicit config interface makes sense to me, over serializing the builders directly. I also agree that being able to "hydrate" from an arbitrary list of key value pairs, is a compelling interface. I think the major challenge with such an interface is documenting it well, as you don't have the benefit of the compiler / rustdoc to do the heavy lifting for you, but that is certainly not insurmountable. fn from_kv(cfg: &HashMap<String, String>) -> Self Or even a fn with_option(self, key: &str, value: &str) -> Result<Self> or something, no need to constrain to being a HashMap If there is general interest already I'd be happy to open a PR for a more concrete discussion That would be amazing —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
