Hi all, Thanks for the discussion and Eundo’s work. I’m +0 on the current PR and won’t block the merge.
I still think the schema name should be a Polaris-owned property, with Polaris mapping it to each driver’s mechanism. Exposing currentSchema directly leaks that implementation detail and makes a future abstraction harder to introduce. If this merges as-is, I’d like us to track that abstraction as a follow-up before adding another JDBC driver. Yufei On Fri, Aug 28, 2026 at 12:55 AM Alexandre Dutra <[email protected]> wrote: > Hi Eundo, > > Thank you so much for the good work you did on #4945. > > I propose to merge your PR today, by EOD. If someone disagrees, please > let me know. > > Thanks, > Alex > > On Fri, Aug 28, 2026 at 4:22 AM Eundo Lee <[email protected]> wrote: > > > > Hi all, > > > > This is just a friendly reminder for PR #4945 (Make the Relational > > JDBC schema name configurable). > > I understand that the maintainers are quite busy with preparation > > of the 1.8.0 release. I would love to see this PR make it into 1.9.0 > > so that my org can deploy and use Polaris in production. > > > > Thank you. > > > > With regards, > > Eundo > > > > > > 2026년 8월 21일 (금) 오후 12:40, Eundo Lee <[email protected]>님이 작성: > > > > > 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 > > >> > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > > >> > > > >> > > > >
