collado-mike commented on PR #459: URL: https://github.com/apache/polaris/pull/459#issuecomment-2499158130
> Another option would be to make the whole implementation swappable as you mentioned, which could be implemented in a backward compatible way: if a custom type is specified, use it, otherwise use the default. I think this is a reasonable approach and I think this should address the concern of _where_ we get the dynamic config. A Quarkus impl can use whatever the smallrye config structure internally, but we can't tie it to that. The `PolarisConfigurationStore` is intended to support feature rollouts and feature configuraiton globally, but also to be fine-tuned at the realm-level or catalog level. Ultimately, I think it's going to need to allow for namespace and table-level configuration as well. Configuration should be inheritable, so it'll have to have the concept of table-lineage (i.e., table inherits from namspace inherits from catalog inherits from service) and we're just not going to see that in a generalized configuration framework. I'm all for not reinventing the wheel, but we shouldn't hand-wave over the details and pretend it all looks like a configuration file parser. -- 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]
