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