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