adutra commented on PR #459:
URL: https://github.com/apache/polaris/pull/459#issuecomment-2500016857
> 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 also would prefer this approach, as it is CDI-friendly.
But I also think that, before diving head first on making things "dynamic",
we should take some time to design a revamped `PolarisConfigurationStore` SPI
that would address all the requirements. I've seen the below requirements
already voiced (there may be others):
* Ability to (optionally?) hot-reload.
* Ability to merge layers of configuration: application > realm > namespace
> table.
* Ability to swap implementations (mostly to fetch configuration from
different sources).
But the current `PolarisConfigurationStore` API does not surface any of
that. E.g. there is no `hotReload()` method; there is no `merge()` method.
Moreover, none of the methods take a `realm`, or a `table` as argument –
instead, the realm is "implicitly passed" through a `ThreadLocal` in
`CallContext`, and becomes an implementation detail. This makes me think that
`PolarisConfigurationStore` needs a complete redesign.
On top of that, I always wondered why `PolarisConfiguration` has such a
strange shape. Instead of a classic config bean:
```java
interface PolarisConfiguration {
boolean configX();
Optional<String> configY();
List<String> configZ();
}
```
... that each implementor would be free to implement their own way, we have:
```java
public class PolarisConfiguration<T> {
public static final PolarisConfiguration<Boolean> CONFIG_X = ...
public static final PolarisConfiguration<String> CONFIG_Y = ...
public static final PolarisConfiguration<List<String> CONFIG_Z = ...
}
```
... which is a lot harder to extend, or to make "dynamic" or "layered". And
involves many runtime casts that are error-prone, cf
`PolarisConfigurationStore#tryCast()`. So, again, I think
`PolarisConfiguration` also needs a complete redesign.
I would therefore suggest that we embrace the big picture and redesign
`PolarisConfigurationStore` and `PolarisConfiguration` with all the above
considerations and requirements in mind, before adding more features such as
"dynamic resolution".
--
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]
