-
Notifications
You must be signed in to change notification settings - Fork 344
Move JDBC Quarkus configuration to the JDBC persistence module #3281
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
base: main
Are you sure you want to change the base?
Changes from 3 commits
bfe6530
715652c
e4ebacc
9599cff
dc4e343
11a71cb
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 |
|---|---|---|
|
|
@@ -18,8 +18,10 @@ | |
| */ | ||
| package org.apache.polaris.persistence.relational.jdbc; | ||
|
|
||
| import io.smallrye.config.ConfigMapping; | ||
| import java.util.Optional; | ||
|
|
||
| @ConfigMapping(prefix = "polaris.persistence.relational.jdbc") | ||
|
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 do not oppose this change, but I'd like to highlight that this will impose the config naming convention defined in this annotation on downstream projects. It may be possible to provide a different config object for JDBC downstream or it may not be... I cannot say for sure. Old code delegated runtime configuration to the server runtime, so this may be a behaviour change in downstream projects. Given that NoSQL code follows a similar approach (not splitting interfaces and |
||
| public interface RelationalJdbcConfiguration { | ||
| // max retries before giving up | ||
| Optional<Integer> maxRetries(); | ||
|
|
||
This file was deleted.
This file was deleted.
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.
This new dependency is intriguing. This module doesn't need the RDS extension for compilation, not even for tests. If the intent is to create a Polaris server distribution that supports Amazon RDS, I wonder if a better approach wouldn't be to include the RDS Quarkus extension directly in
polaris-server?Conversely, if we decide to keep this dependency here: it is bringing
quarkus-coretransitively. This means that this module becomes de facto a Quarkus module. In this case we should declare the dependencyimplementation(platform(libs.quarkus.bom))and add the Quarkus plugin.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.
Oh I see now, the new dependency was added in #2650 to runtime-common, and @dimas-b is already taking a stab at moving this dependency to the appropriate place in #3252.
I suggest removing this dependency from here and use #3252 to find a better place for it. Wdyt?
Uh oh!
There was an error while loading. Please reload this page.
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.
It isn't new dependency. As you said, it was there for a while. It looks like #3252 didn't do anything about it. Let me know if I missed something.
At this moment, I think it'd be nice to keep as is until we find a better place to hold it. I'm a bit concern that if we removed it here, but didn't get the chance to place it anywhere before next release, it will break users. With that, we might just keep this PR as a pure refactor. WDYT?
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 think it was introduced recently by #2650 – at least I don't see any traces of RDS in Polaris before that.
That said, yes, I agree to move the dependency here and keep thinking about a better home for it.
@dimas-b would you be OK with this?
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 do believe that runtime library dependencies should be concentrated in the
runtime/servermodule.So, I do not think bringing RDS as an
implementationdependency into JDBC persistence is justified. JDBC persistence code should not depend on specific drivers, only on JDBC interfaces.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.
JDBC Persistence and other similar modules compile against their respective interfaces.
The
runtime/servermodule includes drivers (PostgreSQL, RDS, etc.) according to the Polaris project decisions - whatever is supposed to be included in the ASF releases. This does not have to be an all-encompassing list.In this regard, the
runtime/servermodule is essentially the "default" server "package".Downstream projects are not supposed to reuse
runtime/serverdirectly.Downstream projects reuse JDBC Persistence,
runtime/service, etc... as needed and build a customserver. Downstream projects also include libraries / drivers as needed according to the needs of the downstream project.For example, PostgreSQL or RDS code may or may not be included - the decision should rest with the downstream project IMHO. A downstream project may even choose to use a completely different JDBC driver.
Conversely, with the current state of this PR, RDS is an impl. dependency of JDBC Persistence and NOT including it in downstream builds requires extra work at explicitly preventing RDS jars from leaking into custom builds... which is very inconvenient.
Uh oh!
There was an error while loading. Please reload this page.
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.
Thanks for the explanation.
The default dependencies, esp. drivers are not only used by
runtime/server, but also theadminmodule. Instead of adding them to both, how about putting them in theruntime/defaultmodule, and let bothadminandserverdepend onruntime/default? I think the downstream projects are also not supposed to directly reuse theruntime/defaultmodule. WDYT?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.
Good point about adding common server/admin dependencies to
runtime/default... I kind of forgot about it 😅 but indeed I added it a long time ago precisely for this purpose 👍Uh oh!
There was an error while loading. Please reload this page.
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.
With that, I'm probably not going to need #3252 at all :) ... but I'll revisit after this PR is merged ;)
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.
Fixed it in the new commits. I think we should start to put the driver in the default module moving forward. We could move this to the runtime/default as well in a followup.
You can buy me a drink :-)