Support Runtime JDBC Driver Loading and Dynamic Datasource Creation#4984
Support Runtime JDBC Driver Loading and Dynamic Datasource Creation#4984flyrain wants to merge 3 commits into
Conversation
Allow the relational JDBC backend to create and own a Hikari datasource from polaris.persistence.relational.jdbc.* settings when jdbc-url is provided, while preserving the existing Quarkus datasource fallback when it is absent. Cover the new path with unit and integration tests for managed datasource creation, independent datasource creation from separate configs, CockroachDB configuration, production-readiness checks, and loading a JDBC driver from a runtime-provided jar. Document the managed datasource properties and update distribution license metadata for the added runtime dependencies.
| DatasourceOperations( | ||
| DataSource datasource, | ||
| RelationalJdbcConfiguration relationalJdbcConfiguration, | ||
| boolean closeDataSourceOnClose) { |
There was a problem hiding this comment.
closeDataSourceOnClose is awkward to read. How about assumeDataSourceOwnership?
| } | ||
|
|
||
| @Override | ||
| public void close() { |
There was a problem hiding this comment.
When is this close() method called?
|
|
||
| We have 2 options for configuring the persistence backend: | ||
| Polaris can use either a Quarkus-managed datasource or a Polaris-managed JDBC connection pool. When | ||
| `polaris.persistence.relational.jdbc.jdbc-url` is set, Polaris creates the JDBC pool directly; |
There was a problem hiding this comment.
The only advantage of doing this, that I can see, realizes when Polaris is able to load the JDBC driver dynamically. However, I could not find any provisions for dynamic loading in this PR. Did I miss that? 🤔
If repackaging at the binary level is assumed, a Quakus build can be performed at that stage to make the DataSource available via Quarkus-backed CDI.
| @Override | ||
| public void init(Map<String, String> initArgs) { | ||
| initScript = initArgs.get(INIT_SCRIPT); | ||
| polarisManagedDatasource = Boolean.parseBoolean(initArgs.get(POLARIS_MANAGED_DATASOURCE)); |
There was a problem hiding this comment.
Who controls the value of this variable?
Support loading third-party JDBC driver jars from a configured driver directory when Polaris creates the relational JDBC datasource directly. For binary distributions, include visible server and admin jdbc-drivers directories and document the drop-in workflow. Add tests for explicit driver-directory loading and the default quarkus-run.jar sibling directory layout.
Move Polaris-managed JDBC datasource property descriptions into the Quarkus config mapping so generated config docs stay current. Regenerate the relational JDBC config section with copyConfigSectionsToSite.
| boolean success = false; | ||
| try { | ||
| Thread.currentThread().setContextClassLoader(driverClassLoader); | ||
| HikariDataSource dataSource = |
There was a problem hiding this comment.
don't you want to override closeto call closeDriverClassLoader to avoid to leak the driver JarFile?
This PR is intended to support two related requirements:
You can find the test cases for these two requirements in file
JdbcDataSourceFactoryTest.javaChecklist
CHANGELOG.md(if needed)site/content/in-dev/unreleased(if needed)