-
Notifications
You must be signed in to change notification settings - Fork 448
Introduce DataSourceResolver for multi-datasource support in JDBC per… #3960
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 16 commits
136e381
207aa4c
e024bea
96e7ff0
9a07e6e
75e4096
fccb254
9c22635
1e00328
493c386
6311fbe
a36e745
118e046
dc8ffda
7eb2304
7ceaa69
9df42be
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,45 @@ | ||
| /* | ||
| * 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 javax.sql.DataSource; | ||
| import org.apache.polaris.core.context.RealmContext; | ||
|
|
||
| /** | ||
| * Service to resolve the correct {@link DataSource} for a given realm. Note: Currently this is | ||
| * implemented as a foundation for metastore routing. | ||
| */ | ||
| public interface DataSourceResolver { | ||
|
|
||
| /** The type of store representing the workload pattern. */ | ||
| enum StoreType { | ||
| METASTORE, | ||
| METRICS, | ||
| EVENTS | ||
| } | ||
|
|
||
| /** | ||
| * Resolves the DataSource for a given realm and store type. | ||
| * | ||
| * @param realmContext the realm context | ||
| * @param storeType the type of store | ||
| * @return the resolved DataSource | ||
| */ | ||
| DataSource resolve(RealmContext realmContext, StoreType storeType); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm supportive on realm, but we will need to think about the storage type.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @flyrain Could you clarify your concerns regarding StoreType? Are you suggesting a more extensible approach (e.g., String identifiers) or perhaps routing at a different layer? Happy to refine this to better fit the project's direction.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From my POV if we are to introduce |
||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,56 @@ | ||
| /* | ||
| * 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 io.smallrye.common.annotation.Identifier; | ||
| import jakarta.enterprise.context.ApplicationScoped; | ||
| import jakarta.enterprise.inject.Any; | ||
| import jakarta.enterprise.inject.Instance; | ||
| import jakarta.inject.Inject; | ||
| import javax.sql.DataSource; | ||
| import org.apache.polaris.core.context.RealmContext; | ||
| import org.slf4j.Logger; | ||
| import org.slf4j.LoggerFactory; | ||
|
|
||
| /** | ||
| * Default implementation of {@link DataSourceResolver} that routes all realms to a single default | ||
| * {@link DataSource}. | ||
| */ | ||
| @ApplicationScoped | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd rather use
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, let' use |
||
| @Identifier("default") | ||
| public class DefaultDataSourceResolver implements DataSourceResolver { | ||
|
dimas-b marked this conversation as resolved.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I understand why this class was placed in
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about we add a new module like The idea is for
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we use Downstream alternatives will have the the option of reusing
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we have a compelling reason not to turn
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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; | ||
|
|
||
| @Inject | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are probably missing the But more broadly: if this impl can only handle one datasource, the default one, why not just inject it directly?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IIRC, there were some issues with bean not being available in non-JDBC situations (e.g. tests).... that's how I interpret @Subham-KRLX 's message : #3960 (comment)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK makes sense 👍 |
||
| public DefaultDataSourceResolver(@Any Instance<DataSource> defaultDataSource) { | ||
| this.defaultDataSource = defaultDataSource; | ||
| } | ||
|
|
||
| @Override | ||
| public DataSource resolve(RealmContext realmContext, StoreType storeType) { | ||
| LOGGER.debug( | ||
| "Using default DataSource for realm '{}' and store '{}'", | ||
| realmContext.getRealmIdentifier(), | ||
| storeType); | ||
| return defaultDataSource.get(); | ||
| } | ||
| } | ||
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?