> 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 > >> > > > > >> > > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > >> > > > > > >> > > > > >> > > > >> > > > > >> > >> > > > > > > >> > > > > > >> > > > > >> > > >> > > >
