eric-maynard commented on code in PR #1482:
URL: https://github.com/apache/polaris/pull/1482#discussion_r2064866900
##########
quarkus/admin/src/main/java/org/apache/polaris/admintool/config/QuarkusProducers.java:
##########
@@ -76,4 +81,9 @@ public PolarisConfigurationStore configurationStore() {
// A configuration store is not required when running the admin tool.
return new PolarisConfigurationStore() {};
}
+
+ @Produces
+ public JdbcDatasource jdbcDatasource(@ConfigProperty(name =
"polaris.persistence.realm.isolation.type") String realmIsolationType, @All
List<InstanceHandle<DataSource>> dataSources) {
Review Comment:
I think it's important that the configuration capture the notion of a
**realm strategy** -- i.e. do I route requests to a metastore only based on an
explicit configuration for that realm, or do I send all requests to some
metastore by default?
Whether that's done explicitly by configuring a strategy or implicitly
through the presence (or absence) of a default configuration, I think it's
fine. Consider a setup like the following:
The admin has configured DSs for some individual realms:
```
polaris.realm-contex.data-source.realm.realm-1=dsA
polaris.realm-contex.data-source.realm.realm-2=dsA
polaris.realm-contex.data-source.realm.realm-3=dsB
```
A new realm `realm-4` shows up -- I expect things to not work as the system
does not know where to route the request. Later, the admin configures polaris
with a new default:
```
polaris.realm-contex.data-source.default=dsC
```
Now, I expect new realms `realm-4` and `realm-5` to get routed to `dsC`. If
the admin later "promotes" `realm-4` to have its own DS, I would expect the
service to respect that.
The important thing is that the system does not route requests to some
invisible default backend; the admin explicitly must configure the system to
route unknown (unconfigured) realms to some specific DS.
--
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]
