Hi all, I would like to express my sincere gratitude to Alex, Yufei and Robert for the in-depth discussion. I'll update the PR to reflect Robert's additional review on comments and rebase it on top of main.
Personally, although my original approach was to bring in a new Polaris configuration, I eventually leaned towards Alex's point of view. This was because I believed that operators should know and be responsible for JDBC driver configurations. While Polaris can provide guidance on how to configure databases for optimal performance, I believe such configuration should not be coded into the source code. This may come as a surprising black box for operators. However, if the community leans towards a new Polaris configuration, I'm happy to modify my approach. Thanks, Eundo Lee 2026년 8월 21일 (금) 오전 12:25, Robert Stupp <[email protected]>님이 작성: > Thanks, Alex. > > I support making the schema/namespace configurable, and I support moving > forward with the current PR once it is rebased on main and the current > checks > pass. > > The current change gives the supported databases a concrete, driver-native > configuration contract. > > A Polaris-owned property remains a plausible alternative, but it would need > its own defined per-driver mappings, validation, upgrade behavior, and > ownership model. > > The remaining question is whether there is a concrete correctness or > compatibility concern with the current driver-native path that requires a > change before merge. > > At present, I have not seen a concrete correctness or compatibility > requirement that the current driver-native path fails to meet. > > If not, I support merging this PR and treating the Polaris-owned > abstraction > as a clearly scoped follow-up. > > > On Thu, Aug 20, 2026 at 4:48 PM Alexandre Dutra <[email protected]> wrote: > > > Hi Yufei, > > > > Your point that Polaris already branches on DatabaseType is fair, but > > that branching is a cost we try to minimize, not a pattern we should > > build on. > > > > As for the Connector/J documentation you linked, I think it is being > > read slightly out of context: the "Always use Connection.setCatalog() > > rather than the USE database statement" note is a narrow best practice > > for JDBC code that needs to switch databases dynamically at runtime; > > it is not recommending setCatalog() as the standard way to configure > > the initial database connection. The same paragraph makes the primary > > recommendation clear: specify the database in the JDBC URL. > > setCatalog() is a fallback for when the URL has no database. > > > > More broadly, why should Polaris call JDBC APIs at all when standard > > configuration is sufficient? Having Polaris invoke setCatalog() (or > > setSchema()) at connection-initialization time means adding custom > > connection-lifecycle code in Polaris for something operators can > > already express as plain configuration. That is complexity we would > > own and maintain indefinitely. > > > > Anyways, I am not sure we are going to agree on this topic, so it's > > probably best to just disagree and commit. The PR is already approved. > > If no strong objections are raised, I suggest that we merge it in the > > coming days. Would that work for you and for others as well? > > > > Thanks, > > Alex > > > > On Wed, Aug 19, 2026 at 11:09 PM Yufei Gu <[email protected]> wrote: > > > > > > Hi Alex, I agree that MySQL does not have PostgreSQL-style schemas > nested > > > below a database; in MySQL, SCHEMA is a synonym for DATABASE[1], users > > can > > > do either CREATE DATABASE db_name or CREATE SCHEMA db_name. > > > > > > However, I do not think that leaves only the two options of ignoring > the > > > property or rewriting the JDBC URL. Connector/J represents the current > > > MySQL database as a JDBC catalog and explicitly recommends using > > > Connection.setCatalog() to select it[2]. Connector/J can also expose > > > databases through the JDBC schema APIs when databaseTerm=SCHEMA is > > > configured. If and when MySQL is supported, a Polaris-owned property > > could > > > therefore refer to the database namespace containing the Polaris > tables: > > > > > > - PostgreSQL/CockroachDB: a schema > > > - H2: a schema > > > - MySQL: a database/catalog > > > > > > The difference would need to be documented, particularly that MySQL > > cannot > > > place multiple such namespaces inside one database, but the property > > would > > > neither be ignored nor require JDBC URL manipulation. I agree that this > > > entails some database-specific interpretation. My argument is not that > > the > > > mapping is free, but that currentSchema is itself driver-specific and > > moves > > > that interpretation to operators. A Polaris-owned property would keep > the > > > operator-facing default, validation, and upgrade behavior under > Polaris’s > > > control. Polaris already has database-specific handling through > > > DatabaseType and separate bootstrap resources, so this mapping would > fit > > > the existing structure. > > > > > > References: > > > [1] https://dev.mysql.com/doc/refman/8.4/en/create-database.html > > > [2] > > > > > > https://dev.mysql.com/doc/connector-j/en/connector-j-reference-jdbc-url-format.html > > > [3] > > > > > > https://dev.mysql.com/doc/connectors/en/connector-j-connp-props-connection.html > > > > > > Yufei > > > > > > > > > On Wed, Aug 19, 2026 at 3:38 AM Alexandre Dutra <[email protected]> > > wrote: > > > > > > > Hi Yufei, > > > > > > > > I want to challenge the "driver-agnostic abstraction" premise again, > > > > because I believe it is the opposite of what a Polaris-specific > > > > property would deliver. > > > > > > > > For polaris.persistence.relational.jdbc.schema-name to work across > > > > drivers, Polaris would need to translate it into the appropriate > > > > driver-level mechanism for each supported database. > > > > > > > > MySQL is the clearest illustration of why that translation is not > > > > straightforward: MySQL has no concept of a schema below a database, > > > > and therefore there is no "current schema" connection property to > set. > > > > So either Polaris ignores the property on MySQL (making the > > > > abstraction dishonest) or it tries to inject the value into the JDBC > > > > URL (fragile). Neither outcome is better than what we have now in > > > > Eundo's PR. > > > > > > > > Far from hiding driver-specific concerns, a Polaris-owned property > > > > would require us to accumulate per-driver translation logic inside > > > > Polaris, which is exactly what you are trying to avoid, just at a > > > > higher layer. > > > > > > > > Thanks, > > > > Alex > > > > > > > > > > > > On Wed, Aug 19, 2026 at 3:03 AM Yufei Gu <[email protected]> > wrote: > > > > > > > > > > I agree that PostgreSQL is unlikely to change this behavior > > unexpectedly. > > > > > Still, I think Eundo’s original approach is more robust. > Introducing > > a > > > > > Polaris-specific property such as > > > > > polaris.persistence.relational.jdbc.schema-name, instead of relying > > > > > directly on quarkus.datasource.jdbc.additional-jdbc-properties.*, > > would > > > > > provide a stable, driver-agnostic abstraction. This would support > > > > different > > > > > JDBC drivers consistently(e.g., the quakus config doesn't work for > > mysql > > > > > driver) and insulate Polaris from driver-specific configuration > > details > > > > or > > > > > future behavioral changes. > > > > > > > > > > This is less about anticipating a breaking PostgreSQL change and > more > > > > about > > > > > keeping driver-specific concerns behind a Polaris-owned > configuration > > > > > interface. > > > > > Yufei > > > > > > > > > > > > > > > On Tue, Aug 18, 2026 at 8:00 AM Alexandre Dutra <[email protected] > > > > > > wrote: > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > My main concern is still that currentSchema, after > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties, is part of a > > > > freeform > > > > > > key-value configuration and just happens to be honored by the > > current > > > > > > PostgreSQL driver. We should avoid depending on driver-specific > > > > behavior if > > > > > > possible. > > > > > > > > > > > > I believe you are overstating this risk. > > > > > > > > > > > > JDBC driver configuration does not adhere to any standard, > > resulting > > > > > > in dramatically different syntax for pathing, parameter > delimiters, > > > > > > and authentication placement across database vendors. This is > valid > > > > > > for both JDBC connection strings, and JDBC properties. > > > > > > > > > > > > However, that does not mean JDBC configuration is completely > > > > > > unpredictable. Each vendor explicitly defines, documents, and > > > > > > maintains its driver's supported JDBC properties as part of a > > formal > > > > > > configuration surface. Drivers rarely, if ever, modify these > > > > > > parameters in a breaking manner. > > > > > > > > > > > > As a result, describing additional-jdbc-properties as a "freeform > > > > > > key-value configuration" is misleading, and the concern that the > > > > > > PostgreSQL driver might suddenly alter this behavior is largely > > moot: > > > > > > such a change is highly unlikely. > > > > > > > > > > > > Therefore, Eundo's PR remains the most practical path forward. > > While > > > > > > we could technically embed the schema name in the connection URL > > via > > > > > > quarkus.datasource.jdbc.url, doing so would disrupt existing > > > > > > environments because that property is widely customized. Using > > > > > > additional-jdbc-properties provides a cleaner, > backwards-compatible > > > > > > path for upgrades. > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > On Thu, Aug 13, 2026 at 12:16 AM Yufei Gu <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA > > > > > > > > > > > > > > My main concern is still that currentSchema, after > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties, is part of > a > > > > freeform > > > > > > > key-value configuration and just happens to be honored by the > > current > > > > > > > PostgreSQL driver. We should avoid depending on driver-specific > > > > behavior > > > > > > if > > > > > > > possible. We may need to support additional drivers in the > > future, > > > > and > > > > > > the > > > > > > > PostgreSQL driver's behavior could also change. Don't get me > > wrong. > > > > I'm > > > > > > not > > > > > > > saying these future use cases cannot be addressed, but I think > we > > > > should > > > > > > > avoid introducing them if possible. Given that adding a > > > > Polaris-specific > > > > > > > configuration is relatively easy, I'd suggest going that route. > > > > > > > > > > > > > > The upgrade concern is a relatively minor point. Even if we > ship > > the > > > > > > > default config, existing users would still need to manually > pick > > up > > > > the > > > > > > new > > > > > > > defaults and merge them into their existing configuration. > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 11, 2026 at 7:29 AM Eundo Lee <[email protected]> > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I would like to call for more reviewers' attention to this > > > > discussion > > > > > > and > > > > > > > > PR with > > > > > > > > all respect. > > > > > > > > > > > > > > > > I personally strongly believe that this PR is in the > direction > > of > > > > > > > > introducing Polaris > > > > > > > > to a wider audience. Schema inconfigurability, in my opinion, > > can > > > > in > > > > > > fact > > > > > > > > be the > > > > > > > > single blocker for new users to adopt Polaris. > > > > > > > > > > > > > > > > With that said, I would love to see more reviewers engaging > > with > > > > this > > > > > > > > topic. > > > > > > > > > > > > > > > > With regards, > > > > > > > > Eundo. > > > > > > > > > > > > > > > > > > > > > > > > 2026년 8월 8일 (토) 오후 4:45, Eundo Lee <[email protected]>님이 작성: > > > > > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > > > > > Sorry for the late reply. > > > > > > > > > > > > > > > > > > Thanks, that's a fair thing to be careful about -- an > upgrade > > > > that > > > > > > > > silently > > > > > > > > > starts reading from the wrong schema would be exactly the > > kind of > > > > > > failure > > > > > > > > > an > > > > > > > > > operator wouldn't catch until it's already caused damage. > > Let me > > > > lay > > > > > > out > > > > > > > > > why I > > > > > > > > > believe existing deployments are safe without any operator > > > > action. > > > > > > > > > > > > > > > > > > The shipped defaults in runtime/defaults and the admin tool > > set > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA, > > > > > > > > > which is exactly the schema name the code hard-coded > before. > > So > > > > an > > > > > > > > > operator who > > > > > > > > > upgrades and changes nothing gets the same schema selection > > they > > > > had > > > > > > on > > > > > > > > > the old > > > > > > > > > release, pointed at the schema their prior Polaris already > > > > created. > > > > > > > > > There's no > > > > > > > > > "you must edit your datasource config or you break" step on > > the > > > > > > upgrade > > > > > > > > > path -- > > > > > > > > > the behavior is preserved precisely so that the common case > > > > requires > > > > > > no > > > > > > > > > action. > > > > > > > > > > > > > > > > > > On the "administrators won't touch datasource config during > > an > > > > > > upgrade" > > > > > > > > > point: I > > > > > > > > > agree they generally won't, and the design leans on that > > rather > > > > than > > > > > > > > > against it. > > > > > > > > > The datasource configuration (URL, credentials, and the > > database > > > > > > itself) > > > > > > > > > is the > > > > > > > > > one piece an operator already has to own for JDBC > > persistence to > > > > > > work at > > > > > > > > > all, so > > > > > > > > > we're not introducing a new configuration surface they have > > to > > > > learn > > > > > > -- > > > > > > > > > we're > > > > > > > > > shipping a default value in the same block they already > > provide. > > > > > > > > > > > > > > > > > > The one genuine behavior change is that Polaris no longer > > issues > > > > > > CREATE > > > > > > > > > SCHEMA, > > > > > > > > > so a *fresh* deployment now needs the schema created before > > > > > > bootstrap. > > > > > > > > That > > > > > > > > > doesn't affect existing deployments, whose schema already > > exists > > > > > > from the > > > > > > > > > prior > > > > > > > > > version; it only affects new installs, and it's called out > > as a > > > > > > breaking > > > > > > > > > change > > > > > > > > > in the docs with the two-step procedure. If it would help, > > I'm > > > > happy > > > > > > to > > > > > > > > > make > > > > > > > > > that more prominent in the release notes so a fresh-install > > > > operator > > > > > > > > can't > > > > > > > > > miss > > > > > > > > > it. > > > > > > > > > > > > > > > > > > So concretely: upgrade with no config change -> works, same > > > > schema as > > > > > > > > > before; > > > > > > > > > fresh install -> create the schema first, as documented. I > > don't > > > > see > > > > > > a > > > > > > > > path > > > > > > > > > where an existing operator has to change their setup to > keep > > > > > > working, but > > > > > > > > > if you > > > > > > > > > can think of one I've missed I'd genuinely like to close it > > > > before > > > > > > this > > > > > > > > > lands. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Eundo > > > > > > > > > > > > > > > > > > 2026년 8월 4일 (화) 오전 7:28, Yufei Gu <[email protected]>님이 > > 작성: > > > > > > > > > > > > > > > > > >> Other than coupling the data source schema name to the > > driver's > > > > > > > > behavior, > > > > > > > > >> I'm also concerned that this could easily break downstream > > > > systems > > > > > > if > > > > > > > > >> administrators miss the datasource configuration changes > in > > the > > > > new > > > > > > > > >> Polaris > > > > > > > > >> release. I don't think most administrators would update > > their > > > > > > datasource > > > > > > > > >> configuration as part of an upgrade, but I could be wrong. > > > > > > > > >> > > > > > > > > >> Yufei > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> On Mon, Aug 3, 2026 at 5:38 AM Alexandre Dutra < > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > >> > Hi all, > > > > > > > > >> > > > > > > > > > >> > I think it's fine to just document that currentSchema is > > > > specific > > > > > > to > > > > > > > > >> > PostgreSQL. Drivers are very diverse in terms of design > > and > > > > > > > > >> > configuration surface; I think it's also fine to let the > > onus > > > > > > fall on > > > > > > > > >> > operators to properly configure the connection according > > to > > > > their > > > > > > > > >> > driver's capabilities and configuration facade. > > > > > > > > >> > > > > > > > > > >> > Thanks, > > > > > > > > >> > Alex > > > > > > > > >> > > > > > > > > > >> > On Wed, Jul 22, 2026 at 5:43 AM Eundo Lee < > > [email protected]> > > > > > > wrote: > > > > > > > > >> > > > > > > > > > > >> > > Hi Yufei, > > > > > > > > >> > > > > > > > > > > >> > > Thanks for raising this — it's a fair point, and I > agree > > > > it's > > > > > > worth > > > > > > > > >> the > > > > > > > > >> > > community weighing in. > > > > > > > > >> > > > > > > > > > > >> > > I looked into how MySQL handles this and tested it > > against a > > > > > > real > > > > > > > > >> MySQL > > > > > > > > >> > > instance (Connector/J 9.1.0). A couple of findings > > that, I > > > > > > think, > > > > > > > > let > > > > > > > > >> the > > > > > > > > >> > > driver-configuration approach hold up even with MySQL > > in the > > > > > > > > picture: > > > > > > > > >> > > > > > > > > > > >> > > - MySQL has no notion of a schema below a database — > > > > "schema" > > > > > > and > > > > > > > > >> > > "database" are synonyms there. The namespace is > > selected > > > > by > > > > > > the > > > > > > > > >> > database > > > > > > > > >> > > in the JDBC URL, which is exactly what the MySQL PR > > > > (#4281) > > > > > > > > already > > > > > > > > >> > does: > > > > > > > > >> > > jdbc:mysql://<host>:3306/POLARIS_SCHEMA. So MySQL's > > > > namespace > > > > > > is > > > > > > > > >> also > > > > > > > > >> > > selected through standard datasource configuration; > > it's > > > > just > > > > > > a > > > > > > > > >> > different > > > > > > > > >> > > property, because that is how MySQL natively models > > it. In > > > > > > both > > > > > > > > >> cases > > > > > > > > >> > the > > > > > > > > >> > > persistence layer stays agnostic of the schema name. > > > > > > > > >> > > > > > > > > > > >> > > - The shipped currentSchema default is harmless on > > MySQL. > > > > It is > > > > > > set > > > > > > > > on > > > > > > > > >> > the > > > > > > > > >> > > default (PostgreSQL) datasource, and #4281 exposes > > MySQL > > > > as a > > > > > > > > >> separate > > > > > > > > >> > > named datasource, so it does not apply there. And > > even if > > > > it > > > > > > were > > > > > > > > >> > applied, > > > > > > > > >> > > MySQL Connector/J silently ignores currentSchema — I > > > > verified > > > > > > that > > > > > > > > >> it > > > > > > > > >> > > connects without error and the property simply has > no > > > > effect. > > > > > > (A > > > > > > > > >> > database > > > > > > > > >> > > in the URL also overrides currentSchema on both > > > > PostgreSQL and > > > > > > > > >> MySQL.) > > > > > > > > >> > > > > > > > > > > >> > > So a Polaris-owned generic schema-name would not > > actually > > > > buy > > > > > > MySQL > > > > > > > > >> > > anything: there is nothing below the database for it > to > > > > > > translate > > > > > > > > to, > > > > > > > > >> so > > > > > > > > >> > it > > > > > > > > >> > > would either no-op or duplicate the URL database — > while > > > > > > > > reintroducing > > > > > > > > >> > the > > > > > > > > >> > > extension-point change and the per-driver > quoting/casing > > > > logic > > > > > > that > > > > > > > > >> this > > > > > > > > >> > > rework removed. > > > > > > > > >> > > > > > > > > > > >> > > That said, the generic approach does offer one real > > thing: a > > > > > > single > > > > > > > > >> > uniform > > > > > > > > >> > > knob, so operators don't have to know each driver's > > idiom. > > > > My > > > > > > > > >> preference > > > > > > > > >> > is > > > > > > > > >> > > the driver-configuration approach, but I'm genuinely > > fine > > > > either > > > > > > > > way, > > > > > > > > >> > and if > > > > > > > > >> > > the community leans toward the uniform knob it's a > > bounded > > > > > > change to > > > > > > > > >> > layer > > > > > > > > >> > > back on. > > > > > > > > >> > > > > > > > > > > >> > > To avoid surprises in the meantime, I've documented in > > the > > > > Helm > > > > > > > > values > > > > > > > > >> > that > > > > > > > > >> > > currentSchema is PostgreSQL/CockroachDB-specific and > is > > > > silently > > > > > > > > >> ignored > > > > > > > > >> > by > > > > > > > > >> > > MySQL (where the schema is the database in the URL). > > > > > > > > >> > > > > > > > > > > >> > > Thanks again for the careful review! > > > > > > > > >> > > > > > > > > > > >> > > Eundo > > > > > > > > >> > > > > > > > > > > >> > > 2026년 7월 22일 (수) 오전 10:10, Yufei Gu < > > [email protected] > > > > >님이 > > > > > > 작성: > > > > > > > > >> > > > > > > > > > > >> > > > Thanks a lot for working on this, Eundo. The new > > > > approach[1] > > > > > > > > >> > introduces a > > > > > > > > >> > > > hard dependency on the driver's behavior. It's fine > > now > > > > since > > > > > > the > > > > > > > > >> > > > PostgreSQL driver is the only JDBC driver needed in > > > > > > production. > > > > > > > > >> > However, > > > > > > > > >> > > > there is an effort to support MySQL. In that case, > we > > may > > > > > > need a > > > > > > > > >> > different > > > > > > > > >> > > > way to inject the schema name. > > > > > > > > >> > > > The previous approach is a more generic in that > > regard, > > > > > > though it > > > > > > > > >> > involves > > > > > > > > >> > > > a bit more complexity. Personally, I'm fine with > > either > > > > > > approach, > > > > > > > > >> but > > > > > > > > >> > I'd > > > > > > > > >> > > > like to hear more opinions from the community. > > > > > > > > >> > > > > > > > > > > > >> > > > 1. > > > > > > > > > > https://github.com/apache/polaris/pull/4945/changes#r3626702105 > > > > > > > > >> > > > > > > > > > > > >> > > > Yufei > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > On Tue, Jul 21, 2026 at 12:40 AM Eundo Lee < > > > > [email protected] > > > > > > > > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > > Hi all, > > > > > > > > >> > > > > > > > > > > > > >> > > > > A quick update: the rework discussed on this > thread > > has > > > > > > landed > > > > > > > > on > > > > > > > > >> > the PR, > > > > > > > > >> > > > > and it now follows the direction Alex proposed — > the > > > > > > Relational > > > > > > > > >> JDBC > > > > > > > > >> > > > > persistence layer is completely agnostic of the > > schema > > > > name. > > > > > > > > >> > > > > > > > > > > > > >> > > > > What changed: > > > > > > > > >> > > > > > > > > > > > > >> > > > > - The schema is selected entirely through the JDBC > > > > driver's > > > > > > > > >> > currentSchema > > > > > > > > >> > > > > connection property; the persistence code no > > longer > > > > > > qualifies > > > > > > > > >> SQL, > > > > > > > > >> > > > > validates a schema name, or sets a session > schema. > > > > There > > > > > > is no > > > > > > > > >> > > > > Polaris-level configuration option and no > > > > extension-point > > > > > > > > >> change -- > > > > > > > > >> > > > > RelationalJdbcConfiguration is unchanged from > > main. > > > > > > > > >> > > > > > > > > > > > > >> > > > > - A default is shipped in runtime/defaults and the > > admin > > > > > > tool > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > (quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA), > > > > > > > > >> > > > > so upgrades and the out-of-the-box experience > are > > > > > > unchanged. A > > > > > > > > >> > > > > currentSchema set in the JDBC URL takes > precedence > > > > over it > > > > > > > > >> > (verified > > > > > > > > >> > > > > against PostgreSQL and CockroachDB). > > > > > > > > >> > > > > > > > > > > > > >> > > > > - Polaris no longer issues CREATE SCHEMA: the > > schema is > > > > a > > > > > > > > >> > prerequisite > > > > > > > > >> > > > > created by a DBA. Fresh deployments are a > two-step > > > > > > procedure > > > > > > > > >> > (create > > > > > > > > >> > > > the > > > > > > > > >> > > > > schema, then bootstrap); this is a documented > > breaking > > > > > > change. > > > > > > > > >> The > > > > > > > > >> > > > > getting-started compose assets and the Helm test > > > > fixture > > > > > > > > create > > > > > > > > >> the > > > > > > > > >> > > > > schema at the database-provisioning layer, so > the > > > > > > tutorials > > > > > > > > >> > themselves > > > > > > > > >> > > > > are unchanged. > > > > > > > > >> > > > > > > > > > > > > >> > > > > - The Helm chart exposes > > > > > > > > >> > persistence.relationalJdbc.additionalProperties > > > > > > > > >> > > > > (default {currentSchema: POLARIS_SCHEMA}), which > > also > > > > > > leaves > > > > > > > > >> room > > > > > > > > >> > for > > > > > > > > >> > > > > other JDBC driver properties. > > > > > > > > >> > > > > > > > > > > > > >> > > > > The PR is out of draft and ready for review: > > > > > > > > >> > > > > https://github.com/apache/polaris/pull/4945 > > > > > > > > >> > > > > > > > > > > > > >> > > > > Thanks to Alex for the thorough review that got us > > to a > > > > much > > > > > > > > >> cleaner > > > > > > > > >> > > > > solution, and to Yufei and Dmitri for the input on > > the > > > > > > > > >> > schema-version and > > > > > > > > >> > > > > legacy-script questions. Further review and > > feedback are > > > > > > very > > > > > > > > >> > welcome. > > > > > > > > >> > > > > > > > > > > > > >> > > > > Thanks, > > > > > > > > >> > > > > Eundo > > > > > > > > >> > > > > > > > > > > > > >> > > > > 2026년 7월 21일 (화) 오전 11:16, Eundo Lee < > > [email protected] > > > > >님이 > > > > > > 작성: > > > > > > > > >> > > > > > > > > > > > > >> > > > > > Hi Alex, > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > Thanks for your input! > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > 1. I'll keep my changes on the PR that add the > > default > > > > > > > > >> > > > > > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSc > > > > > > > > >> > > > > > hema=POLARIS_SCHEMA > > > > > > > > >> > > > > > 2. I'll brainstorm further and see if I can find > > some > > > > way! > > > > > > > > >> > > > > > 3. Thanks for the great suggestion. I totally > > agree > > > > and > > > > > > will > > > > > > > > >> > reflect > > > > > > > > >> > > > this > > > > > > > > >> > > > > > in the PR. > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > With regards, > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > Eundo > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > 2026년 7월 21일 (화) 오전 5:23, Alexandre Dutra < > > > > > > [email protected] > > > > > > > > >님이 > > > > > > > > >> > 작성: > > > > > > > > >> > > > > > > > > > > > > > >> > > > > >> Hi Eundo, > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> Thanks for the thorough analysis! I'm glad to > see > > > > that > > > > > > we're > > > > > > > > >> > > > > >> converging to a really nice solution. > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> To your points: > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > I'd therefore propose shipping a default in > > > > > > > > runtime/defaults: > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> +1 on this idea, I think it makes migration a > lot > > > > easier. > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > I think the two-step procedure is the right > > call > > > > for > > > > > > > > >> production > > > > > > > > >> > > > [...] > > > > > > > > >> > > > > >> but it does add a manual step to every > > quickstart, > > > > > > > > >> > docker-compose, and > > > > > > > > >> > > > > Helm > > > > > > > > >> > > > > >> example > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> Indeed. I'm personally OK with that and am sure > > we > > > > can > > > > > > find a > > > > > > > > >> > smart > > > > > > > > >> > > > > >> way to update the quickstart examples > > holistically. > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > the Helm chart's > > > > persistence.relationalJdbc.schemaName > > > > > > > > value > > > > > > > > >> > could > > > > > > > > >> > > > > stay > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> I would rather suggest a new field: > > > > > > > > >> > > > > >> > persistence.relationalJdbc.additionalProperties, > > with > > > > > > default > > > > > > > > >> > value: { > > > > > > > > >> > > > > >> currentSchema: POLARIS_SCHEMA }. This way we > also > > > > leave > > > > > > the > > > > > > > > >> door > > > > > > > > >> > open > > > > > > > > >> > > > > >> for users that want to customize other JDBC > > > > properties. > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> Thank you for working on this! > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> Alex > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> On Sun, Jul 19, 2026 at 1:24 PM Eundo Lee < > > > > > > [email protected] > > > > > > > > > > > > > > > > > >> > wrote: > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > Hi Alex, > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > Thanks for taking this further — I agree with > > the > > > > > > > > direction. > > > > > > > > >> > > > > >> Driver-level > > > > > > > > >> > > > > >> > schema selection is the logical endpoint of > the > > > > review > > > > > > so > > > > > > > > far > > > > > > > > >> > > > > >> > (statement-level -> connection-level -> > > > > driver-level), > > > > > > and > > > > > > > > it > > > > > > > > >> > > > removes > > > > > > > > >> > > > > >> the > > > > > > > > >> > > > > >> > hardest parts of the PR from Polaris's > > > > responsibility > > > > > > > > >> entirely: > > > > > > > > >> > > > > quoting, > > > > > > > > >> > > > > >> > identifier case folding, validation, and the > > > > > > per-database > > > > > > > > SET > > > > > > > > >> > > > > statements > > > > > > > > >> > > > > >> > all become the driver's documented behavior. > It > > > > also > > > > > > helps > > > > > > > > >> with > > > > > > > > >> > > > MySQL > > > > > > > > >> > > > > >> > support later (#3960), and — procedurally > nice > > — it > > > > > > > > >> eliminates > > > > > > > > >> > the > > > > > > > > >> > > > > >> > RelationalJdbcConfiguration change > altogether, > > so > > > > the > > > > > > PR no > > > > > > > > >> > longer > > > > > > > > >> > > > > >> touches > > > > > > > > >> > > > > >> > an extension point at all. Most of the > > > > already-reviewed > > > > > > > > work > > > > > > > > >> > > > > >> (unqualified > > > > > > > > >> > > > > >> > generated SQL, schema-agnostic scripts for > the > > > > current > > > > > > > > schema > > > > > > > > >> > > > version) > > > > > > > > >> > > > > >> > carries over unchanged. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > Two points I'd like to settle before > reworking > > the > > > > PR > > > > > > in > > > > > > > > this > > > > > > > > >> > > > > direction: > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > 1. Upgrade compatibility. Today every > > > > relational-jdbc > > > > > > > > >> > deployment has > > > > > > > > >> > > > > its > > > > > > > > >> > > > > >> > tables in POLARIS_SCHEMA because the code > > and > > > > > > scripts > > > > > > > > >> force > > > > > > > > >> > it. > > > > > > > > >> > > > If > > > > > > > > >> > > > > >> the > > > > > > > > >> > > > > >> > persistence layer becomes fully > > > > schema-agnostic, an > > > > > > > > >> existing > > > > > > > > >> > > > > >> deployment > > > > > > > > >> > > > > >> > that upgrades without adding currentSchema > > to > > > > its > > > > > > JDBC > > > > > > > > >> > > > > configuration > > > > > > > > >> > > > > >> > would resolve unqualified names against > the > > > > default > > > > > > > > search > > > > > > > > >> > path — > > > > > > > > >> > > > > >> > "public" on PostgreSQL — and break (or > > quietly > > > > > > > > bootstrap a > > > > > > > > >> > second > > > > > > > > >> > > > > set > > > > > > > > >> > > > > >> > of tables in public, which is what #1116 > set > > > > out to > > > > > > > > >> avoid). > > > > > > > > >> > I'd > > > > > > > > >> > > > > >> > therefore propose shipping a default in > > > > > > > > runtime/defaults: > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > This covers PostgreSQL and CockroachDB > (the > > > > shipped > > > > > > > > >> drivers; > > > > > > > > >> > H2 > > > > > > > > >> > > > is > > > > > > > > >> > > > > >> > test-only), keeps upgrades and the > > > > out-of-the-box > > > > > > > > >> experience > > > > > > > > >> > > > > >> unchanged, > > > > > > > > >> > > > > >> > and is trivially overridable: pgjdbc > > documents > > > > that > > > > > > > > when a > > > > > > > > >> > > > property > > > > > > > > >> > > > > >> is > > > > > > > > >> > > > > >> > specified both in the URL and in the > > Properties > > > > > > object, > > > > > > > > >> the > > > > > > > > >> > > > > >> Properties > > > > > > > > >> > > > > >> > value is ignored [1] — and > > > > > > additional-jdbc-properties > > > > > > > > >> > reaches the > > > > > > > > >> > > > > >> driver > > > > > > > > >> > > > > >> > through the Properties channel. I verified > > this > > > > > > > > >> empirically > > > > > > > > >> > with > > > > > > > > >> > > > > >> pgjdbc > > > > > > > > >> > > > > >> > 42.7.13 against both PostgreSQL 17 and > > > > CockroachDB: > > > > > > a > > > > > > > > >> > > > currentSchema > > > > > > > > >> > > > > >> URL > > > > > > > > >> > > > > >> > parameter overrides the connection > property > > in > > > > > > both, the > > > > > > > > >> > property > > > > > > > > >> > > > > >> alone > > > > > > > > >> > > > > >> > selects the schema correctly in both, and > > with > > > > > > neither > > > > > > > > set > > > > > > > > >> > the > > > > > > > > >> > > > > >> session > > > > > > > > >> > > > > >> > lands in "public" — which is exactly the > > silent > > > > > > failure > > > > > > > > >> mode > > > > > > > > >> > the > > > > > > > > >> > > > > >> shipped > > > > > > > > >> > > > > >> > default would prevent. (The currentSchema > > value > > > > is > > > > > > also > > > > > > > > >> > > > case-folded > > > > > > > > >> > > > > >> like > > > > > > > > >> > > > > >> > any unquoted identifier on both databases, > > > > > > consistent > > > > > > > > with > > > > > > > > >> > the > > > > > > > > >> > > > > casing > > > > > > > > >> > > > > >> > behavior we already agreed on.) > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > [1] > > > > https://jdbc.postgresql.org/documentation/use/ > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > 2. Bootstrap friction for fresh deployments. > > With > > > > no > > > > > > CREATE > > > > > > > > >> > SCHEMA > > > > > > > > >> > > > > >> issued > > > > > > > > >> > > > > >> > by Polaris, even a default fresh > > installation > > > > needs > > > > > > a > > > > > > > > DBA > > > > > > > > >> (or > > > > > > > > >> > > > init > > > > > > > > >> > > > > >> > script) to run CREATE SCHEMA > polaris_schema > > > > before > > > > > > the > > > > > > > > >> admin > > > > > > > > >> > tool > > > > > > > > >> > > > > can > > > > > > > > >> > > > > >> > bootstrap. I think the two-step procedure > > is the > > > > > > right > > > > > > > > >> call > > > > > > > > >> > for > > > > > > > > >> > > > > >> > production — schema creation is privileged > > DBA > > > > work > > > > > > — > > > > > > > > but > > > > > > > > >> it > > > > > > > > >> > does > > > > > > > > >> > > > > >> add a > > > > > > > > >> > > > > >> > manual step to every quickstart, > > > > docker-compose, and > > > > > > > > Helm > > > > > > > > >> > > > example, > > > > > > > > >> > > > > so > > > > > > > > >> > > > > >> > I'd like the community to explicitly bless > > that > > > > > > > > trade-off. > > > > > > > > >> > The > > > > > > > > >> > > > > >> > getting-started materials would gain an > init > > > > step as > > > > > > > > part > > > > > > > > >> of > > > > > > > > >> > the > > > > > > > > >> > > > > PR. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > One suggestion to keep the operator UX: the > > Helm > > > > > > chart's > > > > > > > > >> > > > > >> > persistence.relationalJdbc.schemaName value > > could > > > > > > stay, but > > > > > > > > >> > instead > > > > > > > > >> > > > of > > > > > > > > >> > > > > >> > mapping to a Polaris property it would simply > > > > render > > > > > > the > > > > > > > > >> > > > > >> > additional-jdbc-properties.currentSchema > > datasource > > > > > > > > property. > > > > > > > > >> > > > > Operators > > > > > > > > >> > > > > >> > keep one discoverable knob; the persistence > > code > > > > stays > > > > > > 100% > > > > > > > > >> > > > > >> > schema-agnostic. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > On tests: agreed this is solvable — H2 > supports > > > > running > > > > > > > > >> > > > initialization > > > > > > > > >> > > > > >> SQL > > > > > > > > >> > > > > >> > via the INIT= URL parameter (e.g. CREATE > > SCHEMA IF > > > > NOT > > > > > > > > EXISTS > > > > > > > > >> > ... \; > > > > > > > > >> > > > > >> > SET SCHEMA ...), which covers schema creation > > and > > > > > > selection > > > > > > > > >> for > > > > > > > > >> > the > > > > > > > > >> > > > > >> > H2-based tests cleanly. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > I'll rework the PR accordingly — it's mostly > > > > deletions > > > > > > at > > > > > > > > >> this > > > > > > > > >> > > > point, > > > > > > > > >> > > > > >> but > > > > > > > > >> > > > > >> > we can > > > > > > > > >> > > > > >> > make additional changes if any disagreements > > arise. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > Also, as Yufei mentioned in the PR comment > > [2], I > > > > > > believe > > > > > > > > the > > > > > > > > >> > > > > community > > > > > > > > >> > > > > >> has > > > > > > > > >> > > > > >> > reached a level of consensus high enough for > > this > > > > PR > > > > > > to be > > > > > > > > >> > moved out > > > > > > > > >> > > > > of > > > > > > > > >> > > > > >> > draft > > > > > > > > >> > > > > >> > state. Moving to your new direction would > > actually > > > > > > > > eliminate > > > > > > > > >> > the new > > > > > > > > >> > > > > >> > extension point > > > > > > > > >> > (polaris.persistence.relational.jdbc.schema-name) as > > > > > > > > >> > > > > >> well. > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > [2] > > > > > > > > >> > > > > > > > > > > > > >> > > > > https://github.com/apache/polaris/pull/4945#discussion_r3583285567 > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > Thanks, > > > > > > > > >> > > > > >> > Eundo > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > 2026년 7월 16일 (목) 오전 1:47, Alexandre Dutra < > > > > > > > > [email protected] > > > > > > > > >> >님이 > > > > > > > > >> > 작성: > > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > >> > > Hi Eundo, > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > I did another review and I think things are > > > > shaping > > > > > > up > > > > > > > > >> nicely. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > I think though that we need to go one step > > > > further > > > > > > and > > > > > > > > make > > > > > > > > >> > the > > > > > > > > >> > > > > whole > > > > > > > > >> > > > > >> > > JDBC persistence layer completely agnostic > > of the > > > > > > schema > > > > > > > > >> > name. The > > > > > > > > >> > > > > >> > > schema name can be provided through > > > > configuration, > > > > > > using > > > > > > > > >> > standard > > > > > > > > >> > > > > >> > > Quarkus configuration properties; the > Agroal > > > > > > datasource > > > > > > > > >> would > > > > > > > > >> > then > > > > > > > > >> > > > > >> > > take care of setting the schema on each > > > > connection. > > > > > > There > > > > > > > > >> is > > > > > > > > >> > > > nothing > > > > > > > > >> > > > > >> > > to do code-wise. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > This imho eliminates all the issues > stemming > > from > > > > > > > > quoting / > > > > > > > > >> > casing > > > > > > > > >> > > > > the > > > > > > > > >> > > > > >> > > schema names, and makes the code a lot more > > > > portable. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > This approach, of course, makes it > > impossible for > > > > > > Polaris > > > > > > > > >> to > > > > > > > > >> > > > issue a > > > > > > > > >> > > > > >> > > CREATE SCHEMA statement on the user's > > behalf. I > > > > > > > > understand > > > > > > > > >> > that > > > > > > > > >> > > > this > > > > > > > > >> > > > > >> > > is a breaking change. > > > > > > > > >> > > > > >> > > But I also think it is a good thing to stop > > > > creating > > > > > > > > >> schemas > > > > > > > > >> > on > > > > > > > > >> > > > the > > > > > > > > >> > > > > >> > > fly: such a statement should be executed by > > DB > > > > > > admins, as > > > > > > > > >> they > > > > > > > > >> > > > > require > > > > > > > > >> > > > > >> > > elevated privileges. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > If we agree with this direction, then the > > > > bootstrap > > > > > > story > > > > > > > > >> > becomes > > > > > > > > >> > > > a > > > > > > > > >> > > > > >> > > two-step procedure: a DB admin first > creates > > the > > > > > > schema, > > > > > > > > >> then > > > > > > > > >> > a > > > > > > > > >> > > > > >> > > Polaris admin invokes the admin tool to > > > > bootstrap the > > > > > > > > >> realm, > > > > > > > > >> > and > > > > > > > > >> > > > > >> > > passes the schema to use via Quarkus > config. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > I'm aware that this may require some > changes > > to > > > > tests > > > > > > > > using > > > > > > > > >> > H2, > > > > > > > > >> > > > but > > > > > > > > >> > > > > >> > > I'm fairly confident there is a way to > > > > initialize the > > > > > > > > >> schema > > > > > > > > >> > in > > > > > > > > >> > > > > these > > > > > > > > >> > > > > >> > > cases. > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > Let me know what you think! > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > Thanks, > > > > > > > > >> > > > > >> > > Alex > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > On Tue, Jul 14, 2026 at 4:24 AM Eundo Lee < > > > > > > > > >> [email protected]> > > > > > > > > >> > > > > wrote: > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > Hi Yufei, > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > Thanks for the quick action. I've updated > > the > > > > PR to > > > > > > > > leave > > > > > > > > >> > > > > historical > > > > > > > > >> > > > > >> > > > DDL scripts unchanged. > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > With regards, > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > Eundo > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > 2026년 7월 14일 (화) 오전 1:45, Yufei Gu < > > > > > > > > [email protected] > > > > > > > > >> >님이 > > > > > > > > >> > 작성: > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > > Hi Eundo, > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > Thanks for the clarification. Just a > > small > > > > > > update, > > > > > > > > the > > > > > > > > >> > > > > >> --schema-version > > > > > > > > >> > > > > >> > > > > option has already been removed from > the > > > > > > bootstrap > > > > > > > > >> > command( > > > > > > > > >> > > > > >> > > > > > > https://github.com/apache/polaris/pull/5044 > > > > ), > > > > > > so I > > > > > > > > >> don't > > > > > > > > >> > > > think > > > > > > > > >> > > > > we > > > > > > > > >> > > > > >> > > need to > > > > > > > > >> > > > > >> > > > > update the historical DDL scripts > > anymore. > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > With that out of the way, I think this > > PR can > > > > > > focus > > > > > > > > on > > > > > > > > >> > making > > > > > > > > >> > > > > the > > > > > > > > >> > > > > >> > > current > > > > > > > > >> > > > > >> > > > > schema configurable and updating the > > current > > > > > > > > bootstrap > > > > > > > > >> > path > > > > > > > > >> > > > > >> > > accordingly. > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > Thanks again for working on this! > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > Yufei > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > On Sat, Jul 11, 2026 at 2:01 AM Eundo > > Lee < > > > > > > > > >> > [email protected]> > > > > > > > > >> > > > > >> wrote: > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > > Hi Yufei, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > I was not aware of the discussion > > regarding > > > > > > keeping > > > > > > > > >> the > > > > > > > > >> > > > latest > > > > > > > > >> > > > > >> schema > > > > > > > > >> > > > > >> > > > > > version only. > > > > > > > > >> > > > > >> > > > > > Thanks for the heads up. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > It seems that you've opened a > separate > > > > > > discussion > > > > > > > > >> > thread on > > > > > > > > >> > > > > the > > > > > > > > >> > > > > >> > > removal > > > > > > > > >> > > > > >> > > > > of > > > > > > > > >> > > > > >> > > > > > --schema-version > > > > > > > > >> > > > > >> > > > > > option from the bootstrap command. So > > I'm > > > > > > guessing > > > > > > > > >> that > > > > > > > > >> > the > > > > > > > > >> > > > > >> removal > > > > > > > > >> > > > > >> > > > > should > > > > > > > > >> > > > > >> > > > > > be out of scope > > > > > > > > >> > > > > >> > > > > > from this PR. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > In that case, in order for the > polaris > > > > > > deployment > > > > > > > > to > > > > > > > > >> > work > > > > > > > > >> > > > > as-is > > > > > > > > >> > > > > >> with > > > > > > > > >> > > > > >> > > a > > > > > > > > >> > > > > >> > > > > > configurable schema, > > > > > > > > >> > > > > >> > > > > > I think we should keep the changes to > > the > > > > > > > > historical > > > > > > > > >> DDL > > > > > > > > >> > > > > >> scripts, and > > > > > > > > >> > > > > >> > > > > > remove the scripts once > > > > > > > > >> > > > > >> > > > > > the --schema-version option is > removed > > > > from the > > > > > > > > >> > bootstrap > > > > > > > > >> > > > > >> command. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > Please feel free to correct me if I'm > > > > wrong. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > Thanks, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > Eundo > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > 2026년 7월 11일 (토) 오전 9:00, Yufei Gu < > > > > > > > > >> > [email protected]>님이 > > > > > > > > >> > > > > 작성: > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > > Hi Eundo, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > Thanks for working on this. Making > > the > > > > schema > > > > > > > > name > > > > > > > > >> > > > > >> configurable is > > > > > > > > >> > > > > >> > > a > > > > > > > > >> > > > > >> > > > > good > > > > > > > > >> > > > > >> > > > > > > idea. I also agree with Alex that > we > > > > should > > > > > > avoid > > > > > > > > >> > setting > > > > > > > > >> > > > > the > > > > > > > > >> > > > > >> > > schema > > > > > > > > >> > > > > >> > > > > > every > > > > > > > > >> > > > > >> > > > > > > time we obtain a connection from > the > > > > pool. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > I do have one minor concern. I > don't > > > > think we > > > > > > > > need > > > > > > > > >> to > > > > > > > > >> > > > touch > > > > > > > > >> > > > > >> the > > > > > > > > >> > > > > >> > > > > > historical > > > > > > > > >> > > > > >> > > > > > > JDBC schemas. We've previously > > discussed > > > > on > > > > > > the > > > > > > > > dev > > > > > > > > >> > > > mailing > > > > > > > > >> > > > > >> list > > > > > > > > >> > > > > >> > > that > > > > > > > > >> > > > > >> > > > > > each > > > > > > > > >> > > > > >> > > > > > > Polaris release should only keep > the > > > > latest > > > > > > > > schema > > > > > > > > >> > > > version. > > > > > > > > >> > > > > >> One > > > > > > > > >> > > > > >> > > small > > > > > > > > >> > > > > >> > > > > > > behavior change would naturally > > follow > > > > from > > > > > > this. > > > > > > > > >> We > > > > > > > > >> > could > > > > > > > > >> > > > > >> remove > > > > > > > > >> > > > > >> > > the > > > > > > > > >> > > > > >> > > > > > > --schema-version option from the > > > > bootstrap > > > > > > > > >> command[1]. > > > > > > > > >> > > > That > > > > > > > > >> > > > > >> option > > > > > > > > >> > > > > >> > > > > allows > > > > > > > > >> > > > > >> > > > > > > users to bootstrap a realm with a > > > > historical > > > > > > > > schema > > > > > > > > >> > > > version. > > > > > > > > >> > > > > >> While > > > > > > > > >> > > > > >> > > it > > > > > > > > >> > > > > >> > > > > may > > > > > > > > >> > > > > >> > > > > > > be useful in some rare cases, I > don't > > > > think > > > > > > it > > > > > > > > >> > provides > > > > > > > > >> > > > > enough > > > > > > > > >> > > > > >> > > value to > > > > > > > > >> > > > > >> > > > > > > justify the added complexity. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > 1. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > https://polaris.apache.org/releases/1.6.0/admin-tool/#bootstrapping-realms-and-principal-credentials > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > Thanks, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > Yufei > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > On Thu, Jul 2, 2026 at 2:08 AM > Eundo > > Lee > > > > < > > > > > > > > >> > > > [email protected] > > > > > > > > >> > > > > > > > > > > > > > >> > > > > >> > > wrote: > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > Thank you for taking your time to > > > > review. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > I've applied your suggestion on > > using > > > > an > > > > > > > > explicit > > > > > > > > >> > > > default > > > > > > > > >> > > > > >> value > > > > > > > > >> > > > > >> > > for > > > > > > > > >> > > > > >> > > > > the > > > > > > > > >> > > > > >> > > > > > > > helm chart. > > > > > > > > >> > > > > >> > > > > > > > For other points I agree very > much > > with > > > > > > your > > > > > > > > >> > direction. > > > > > > > > >> > > > > >> > > > > > > > However, I just wanted to confirm > > with > > > > you > > > > > > the > > > > > > > > >> > design / > > > > > > > > >> > > > > >> > > > > implementation > > > > > > > > >> > > > > >> > > > > > > > details > > > > > > > > >> > > > > >> > > > > > > > before diving in to create more > > > > commits. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > I would greatly appreciate > > additional > > > > > > inputs. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > Thanks, > > > > > > > > >> > > > > >> > > > > > > > Eundo Lee > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > 2026년 7월 1일 (수) 오후 11:57, > Alexandre > > > > Dutra < > > > > > > > > >> > > > > >> [email protected]>님이 > > > > > > > > >> > > > > >> > > 작성: > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > Hi Eundo, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > Thank you for raising this > topic > > and > > > > > > > > providing > > > > > > > > >> an > > > > > > > > >> > > > > initial > > > > > > > > >> > > > > >> draft > > > > > > > > >> > > > > >> > > > > PR! I > > > > > > > > >> > > > > >> > > > > > > > > left a few comments. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > I generally agree with the idea > > of > > > > > > making the > > > > > > > > >> > schema > > > > > > > > >> > > > > name > > > > > > > > >> > > > > >> > > > > > > > > configurable. But I'm not sure > I > > > > agree > > > > > > with > > > > > > > > >> some > > > > > > > > >> > > > design > > > > > > > > >> > > > > >> choices > > > > > > > > >> > > > > >> > > > > made > > > > > > > > >> > > > > >> > > > > > > > > in the PR: for example, I think > > it > > > > would > > > > > > be > > > > > > > > >> > easier to > > > > > > > > >> > > > > let > > > > > > > > >> > > > > >> the > > > > > > > > >> > > > > >> > > > > Agroal > > > > > > > > >> > > > > >> > > > > > > > > pool set the schema on each > JDBC > > > > > > connection, > > > > > > > > >> > rather > > > > > > > > >> > > > than > > > > > > > > >> > > > > >> > > having it > > > > > > > > >> > > > > >> > > > > > set > > > > > > > > >> > > > > >> > > > > > > > > on each SQL statement generated > > by > > > > the > > > > > > > > >> > QueryGenerator. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > Let's keep discussing > > implementation > > > > > > details > > > > > > > > in > > > > > > > > >> > the PR > > > > > > > > >> > > > > >> though. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > Thanks, > > > > > > > > >> > > > > >> > > > > > > > > Alex > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > On Wed, Jul 1, 2026 at 11:30 AM > > 이은도 < > > > > > > > > >> > > > [email protected]> > > > > > > > > >> > > > > >> wrote: > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Hi all, > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > I'd like to get feedback on a > > small > > > > > > > > >> enhancement > > > > > > > > >> > to > > > > > > > > >> > > > the > > > > > > > > >> > > > > >> > > Relational > > > > > > > > >> > > > > >> > > > > > > JDBC > > > > > > > > >> > > > > >> > > > > > > > > > persistence backend before > > moving > > > > the > > > > > > PR > > > > > > > > out > > > > > > > > >> of > > > > > > > > >> > > > draft. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Problem > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > The backend currently > > hard-codes > > > > its > > > > > > > > database > > > > > > > > >> > schema > > > > > > > > >> > > > > as > > > > > > > > >> > > > > >> > > > > > > POLARIS_SCHEMA > > > > > > > > >> > > > > >> > > > > > > > > > -- both in QueryGenerator > > (there's > > > > an > > > > > > > > >> existing > > > > > > > > >> > "// > > > > > > > > >> > > > > >> TODO: make > > > > > > > > >> > > > > >> > > > > > schema > > > > > > > > >> > > > > >> > > > > > > > name > > > > > > > > >> > > > > >> > > > > > > > > > configurable.") and in the > > > > bootstrap > > > > > > SQL > > > > > > > > >> > scripts. > > > > > > > > >> > > > This > > > > > > > > >> > > > > >> makes > > > > > > > > >> > > > > >> > > it > > > > > > > > >> > > > > >> > > > > > > > > impossible > > > > > > > > >> > > > > >> > > > > > > > > > to comply with a > schema-naming > > > > policy > > > > > > that > > > > > > > > >> > > > > organizations > > > > > > > > >> > > > > >> > > might > > > > > > > > >> > > > > >> > > > > > have. > > > > > > > > >> > > > > >> > > > > > > > > > It came up while looking at > > issue > > > > #1116 > > > > > > > > (the > > > > > > > > >> > older > > > > > > > > >> > > > > >> > > EclipseLink > > > > > > > > >> > > > > >> > > > > > "avoid > > > > > > > > >> > > > > >> > > > > > > > > > public schema" > > > > > > > > >> > > > > >> > > > > > > > > > request); the JDBC backend > > fixed > > > > the > > > > > > "not > > > > > > > > >> > public" > > > > > > > > >> > > > part > > > > > > > > >> > > > > >> by > > > > > > > > >> > > > > >> > > > > > > hard-coding a > > > > > > > > >> > > > > >> > > > > > > > > > name, > > > > > > > > >> > > > > >> > > > > > > > > > but the value still isn't > > > > configurable. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Issue: > > > > > > > > >> > > > https://github.com/apache/polaris/issues/4944 > > > > > > > > >> > > > > >> > > > > > > > > > Draft PR: > > > > > > > > >> > > > https://github.com/apache/polaris/pull/4945 > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Proposed change > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Add > > > > > > > > >> > polaris.persistence.relational.jdbc.schema-name, > > > > > > > > >> > > > > >> > > defaulting > > > > > > > > >> > > > > >> > > > > to > > > > > > > > >> > > > > >> > > > > > > > > > POLARIS_SCHEMA so existing > > > > deployments > > > > > > are > > > > > > > > >> > > > unaffected. > > > > > > > > >> > > > > >> The > > > > > > > > >> > > > > >> > > value > > > > > > > > >> > > > > >> > > > > is > > > > > > > > >> > > > > >> > > > > > > > > > validated as a plain SQL > > identifier > > > > > > (it's > > > > > > > > >> > > > interpolated > > > > > > > > >> > > > > >> into > > > > > > > > >> > > > > >> > > SQL, > > > > > > > > >> > > > > >> > > > > > not > > > > > > > > >> > > > > >> > > > > > > > > > bound). Bootstrap scripts > use a > > > > > > ${schema} > > > > > > > > >> > > > placeholder > > > > > > > > >> > > > > >> > > substituted > > > > > > > > >> > > > > >> > > > > > at > > > > > > > > >> > > > > >> > > > > > > > > > script-execution time so the > > > > configured > > > > > > > > >> schema > > > > > > > > >> > is > > > > > > > > >> > > > > >> created and > > > > > > > > >> > > > > >> > > > > used > > > > > > > > >> > > > > >> > > > > > > > > > consistently. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Points I'd like input on > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > 1. This adds a method to > > > > > > > > >> > > > RelationalJdbcConfiguration, > > > > > > > > >> > > > > >> which > > > > > > > > >> > > > > >> > > is an > > > > > > > > >> > > > > >> > > > > > > > > > extension point -- hence > > this > > > > > > discussion > > > > > > > > >> per > > > > > > > > >> > > > > >> > > CONTRIBUTING.md. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > 2. To wire the schema > through, > > I > > > > > > converted > > > > > > > > >> > > > > >> QueryGenerator > > > > > > > > >> > > > > >> > > from a > > > > > > > > >> > > > > >> > > > > > > static > > > > > > > > >> > > > > >> > > > > > > > > > utility to an instance > > bound to > > > > the > > > > > > > > >> schema. > > > > > > > > >> > > > That's > > > > > > > > >> > > > > >> the > > > > > > > > >> > > > > >> > > bulk of > > > > > > > > >> > > > > >> > > > > > the > > > > > > > > >> > > > > >> > > > > > > > > diff > > > > > > > > >> > > > > >> > > > > > > > > > (mechanical call-site > > updates). > > > > An > > > > > > > > >> > alternative is > > > > > > > > >> > > > > >> > > threading > > > > > > > > >> > > > > >> > > > > the > > > > > > > > >> > > > > >> > > > > > > > schema > > > > > > > > >> > > > > >> > > > > > > > > > through method parameters; > > the > > > > > > instance > > > > > > > > >> > approach > > > > > > > > >> > > > > >> seemed > > > > > > > > >> > > > > >> > > > > cleaner, > > > > > > > > >> > > > > >> > > > > > > but > > > > > > > > >> > > > > >> > > > > > > > > I'm > > > > > > > > >> > > > > >> > > > > > > > > > happy to change direction. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > 3. For the admin tool, I > > exposed > > > > the > > > > > > schema > > > > > > > > >> as > > > > > > > > >> > the > > > > > > > > >> > > > > same > > > > > > > > >> > > > > >> > > config > > > > > > > > >> > > > > >> > > > > > > property > > > > > > > > >> > > > > >> > > > > > > > > > rather than a separate CLI > > > > flag, so > > > > > > the > > > > > > > > >> admin > > > > > > > > >> > > > tool > > > > > > > > >> > > > > >> and > > > > > > > > >> > > > > >> > > server > > > > > > > > >> > > > > >> > > > > > > can't > > > > > > > > >> > > > > >> > > > > > > > > > bootstrap into different > > > > schemas. > > > > > > Let me > > > > > > > > >> > know if > > > > > > > > >> > > > a > > > > > > > > >> > > > > >> CLI > > > > > > > > >> > > > > >> > > flag is > > > > > > > > >> > > > > >> > > > > > > > > preferred > > > > > > > > >> > > > > >> > > > > > > > > > despite that drift risk. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Feedback welcome -- I'll hold > > the > > > > PR in > > > > > > > > draft > > > > > > > > >> > until > > > > > > > > >> > > > > >> there's > > > > > > > > >> > > > > >> > > > > > > consensus. > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > Thanks, > > > > > > > > >> > > > > >> > > > > > > > > > Eundo Lee > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
