Introduce DataSourceResolver for multi-datasource support in JDBC per… #3960
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| /* | ||
| * Licensed to the Apache Software Foundation (ASF) under one | ||
| * or more contributor license agreements. See the NOTICE file | ||
| * distributed with this work for additional information | ||
| * regarding copyright ownership. The ASF licenses this file | ||
| * to you under the Apache License, Version 2.0 (the | ||
| * "License"); you may not use this file except in compliance | ||
| * with the License. You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, | ||
| * software distributed under the License is distributed on an | ||
| * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
| * KIND, either express or implied. See the License for the | ||
| * specific language governing permissions and limitations | ||
| * under the License. | ||
| */ | ||
| package org.apache.polaris.persistence.relational.jdbc; | ||
|
|
||
| import java.util.Set; | ||
| import javax.sql.DataSource; | ||
|
|
||
| /** | ||
| * Service to resolve the correct {@link DataSource} for a given realm and store | ||
| * type. | ||
| * This enables isolating different workloads (e.g., entity metadata vs metrics | ||
| * vs events) | ||
| * into different physical databases or connection pools. | ||
| */ | ||
| public interface DataSourceResolver { | ||
|
|
||
| String STORE_TYPE_MAIN = "main"; | ||
|
Contributor
Author
There was a problem hiding this comment. I have refactored the store types into the StoreType enum as suggested. This makes the resolution logic much cleaner and more type-safe. |
||
| String STORE_TYPE_METRICS = "metrics"; | ||
| String STORE_TYPE_EVENTS = "events"; | ||
|
|
||
| /** | ||
| * Resolves the DataSource for a given realm and store type. | ||
| * | ||
| * @param realmId the realm identifier | ||
| * @param storeType the type of store (e.g., main, metrics, events) | ||
| * @return the resolved DataSource | ||
| */ | ||
| DataSource resolve(String realmId, String storeType); | ||
|
|
||
| /** | ||
| * Returns all unique DataSources managed by this resolver. | ||
| * This is useful for global operations like schema initialization against all | ||
| * data sources. | ||
| * | ||
| * @return a set of all DataSources | ||
| */ | ||
| Set<DataSource> getAllUniqueDataSources(); | ||
|
Contributor
There was a problem hiding this comment. It's fine to have the "list all" method, but I tend to think it needs a separate interface because it's a different use case. Specifically, providing a DataSource per realm does not have to be co-location with the code to list all data sources. The former is a Server runtime concerns, the later is more of an Admin tool concern. |
||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,67 @@ | ||
| /* | ||
| * Licensed to the Apache Software Foundation (ASF) under one | ||
| * or more contributor license agreements. See the NOTICE file | ||
| * distributed with this work for additional information | ||
| * regarding copyright ownership. The ASF licenses this file | ||
| * to you under the Apache License, Version 2.0 (the | ||
| * "License"); you may not use this file except in compliance | ||
| * with the License. You may obtain a copy of the License at | ||
| * | ||
| * http://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, | ||
| * software distributed under the License is distributed on an | ||
| * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
| * KIND, either express or implied. See the License for the | ||
| * specific language governing permissions and limitations | ||
| * under the License. | ||
| */ | ||
| package org.apache.polaris.persistence.relational.jdbc; | ||
|
|
||
| import jakarta.enterprise.context.ApplicationScoped; | ||
| import jakarta.enterprise.inject.Instance; | ||
| import jakarta.inject.Inject; | ||
| import java.util.HashSet; | ||
| import java.util.Set; | ||
| import javax.sql.DataSource; | ||
| import org.slf4j.Logger; | ||
| import org.slf4j.LoggerFactory; | ||
|
|
||
| /** | ||
| * Default implementation of {@link DataSourceResolver} that routes all realms | ||
| * and store types to a | ||
| * single default {@link DataSource}. This serves as both the production default | ||
| * and the base for | ||
| * multi-datasource extensions. | ||
| * | ||
| * <p> | ||
| * To enable per-realm or per-store datasource routing, this class can be | ||
| * extended or replaced | ||
| * with a custom implementation that resolves named datasources based on | ||
| * configuration. | ||
| */ | ||
| @ApplicationScoped | ||
|
Contributor
There was a problem hiding this comment. IIUC, the current extension story is still a bit fragile here. This default resolver is just an unqualified
Contributor
There was a problem hiding this comment. Whoever introduces an alternative implementation for This is a common pattern in Polaris in a few other extension points.
Contributor
There was a problem hiding this comment. I'd rather use
Contributor
There was a problem hiding this comment. Ok, let' use |
||
| public class DefaultDataSourceResolver implements DataSourceResolver { | ||
|
dimas-b marked this conversation as resolved.
Contributor
There was a problem hiding this comment. I'm not sure I understand why this class was placed in
Contributor
There was a problem hiding this comment. Actually the question of where to place implementations of this interface is a tricky one. When designing a true multi-datasource implementation, it will need the Quarkus Agroal extension, and therefore, would likely have to live in It would look like this: @ApplicationScoped
@Identifier("per-realm")
public class PerRealmDataSourceResolver implements DataSourceResolver {
private static final Logger LOGGER = LoggerFactory.getLogger(DefaultDataSourceResolver.class);
@Override
public DataSource resolve(RealmContext realmContext, StoreType storeType) {
String dataSourceName = findDataSourceName(realmContext, storeType);
LOGGER.debug(
"Using DataSource '{}' for realm '{}' and store '{}'",
dataSourceName,
realmContext.getRealmIdentifier(),
storeType);
return AgroalDataSourceUtil.dataSourceIfActive(dataSourceName)
.orElseThrow(
() ->
new IllegalStateException(
"DataSource '" + dataSourceName + "' is not active or does not exist"));
}
private String findDataSourceName(RealmContext realmContext, StoreType storeType) {
...
}
}But the problem is that I think this needs some more thinking.
Contributor
There was a problem hiding this comment. How about we add a new module like The idea is for
Contributor
There was a problem hiding this comment. If we use Downstream alternatives will have the the option of reusing
Contributor
There was a problem hiding this comment. Do we have a compelling reason not to turn
Contributor
There was a problem hiding this comment. Only "general principles" kind of reason 🙂 I tend to think it valuable to isolate runtime / CDI concerns from the basic code / logic of a particular component like JDBC persistence. In that regard, ideally, I believe the NoSQL Persistence impl and the OPA Authorizer follow similar principles (perhaps varying in degree, but similar in essence). I also proposed a similar refactoring for the Admin tool in #3947. I do not really know whether this matters for downstream Polaris users right now 🤔 🤷 In my personal experience, I find that it is much easier to include another module into a build than struggle with excluding intruding dependencies 😅 I know some concerns were raised about module proliferation in Polaris, but from my POV, Gradle is able to deal with a large number of modules very well, so I personally do not see it as an issue.
Contributor
There was a problem hiding this comment. Looking at the evolution of this PR (and this class specifically), I think it's probably fine to move CDI/quarkus-related code into the |
||
|
|
||
| private static final Logger LOGGER = LoggerFactory.getLogger(DefaultDataSourceResolver.class); | ||
|
|
||
| private final Instance<DataSource> defaultDataSource; | ||
|
Contributor
There was a problem hiding this comment. Does this have to be an |
||
|
|
||
| @Inject | ||
| public DefaultDataSourceResolver(Instance<DataSource> defaultDataSource) { | ||
| this.defaultDataSource = defaultDataSource; | ||
| } | ||
|
|
||
| @Override | ||
| public DataSource resolve(String realmId, String storeType) { | ||
| LOGGER.debug("Using default DataSource for realm '{}' and store '{}'", realmId, storeType); | ||
| return defaultDataSource.get(); | ||
| } | ||
|
|
||
| @Override | ||
| public Set<DataSource> getAllUniqueDataSources() { | ||
| Set<DataSource> dataSources = new HashSet<>(); | ||
| dataSources.add(defaultDataSource.get()); | ||
| return dataSources; | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this contract is getting a bit ahead of the implementation. This PR only wires
METASTORE, but the SPI already publishesMETRICSandEVENTSas if those routing modes were part of the current supported surface. Would it make sense to keep the first step narrower and add newStoreTypevalues only once the corresponding paths are actually routed through this resolver?