Hi Dmitri, Thank you for your response, and for letting me know that the dev mailing list is the preferred channel for this discussion.
Since my last day with my current employer is approaching, I am including my personal email address in this thread. Thank you again for your time and guidance. :) Hope you have a fantastic week. Best regards, Yong-Jin Lee On Tue, Aug 11, 2026 at 12:26 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yong-Jin, > > Thanks for your contribution! > > I looked briefly at the PR and I think it is a valuable change. However, > I'm not personally up-to-date on the UI code to approve it. > > This may have to wait a week or two for people to return from vacations :) > > Re: slack: if the current join link does not work (expired), please start > a dedicated thread on `dev`. The link needs to be reset every now and again. > > That said, `dev` emails (like this one) are preferable to slack > for code-level discussions. Slack is fine for how-to discussions and > user-level problems, but changes to the project and related tooling are > best discussed on `dev` to follow ASF practices. > > Cheers, > Dmitri. > > On Tue, Aug 11, 2026 at 11:22 AM Yong Jin Lee via dev < > [email protected]> wrote: > >> Hi all, >> >> I encountered an issue in the Polaris console while setting up an external >> catalog and have filed a GitHub issue and an associated PR. >> >> Currently, the create-catalog form offers all three EXTERNAL connection >> types but fails to collect the type-specific fields: `remoteCatalogName` >> for ICEBERG_REST, and `warehouse` for HADOOP and HIVE. Because >> ConnectionConfigInfo in the console's types only mirrors the base schema, >> these subtype fields have no representation. While the server accepts the >> resulting catalog, it cannot resolve against a prefix-scoped remote. >> Additionally, there is no repair path since UpdateCatalogRequest does not >> accept connectionConfigInfo. >> >> Here are the links to the issue and PR: >> - Issue: https://github.com/apache/polaris-tools/issues/266 >> - PR: https://github.com/apache/polaris-tools/pull/267 >> >> The PR flattens both fields onto ConnectionConfigInfo, matching how >> StorageConfigInfo handles the S3/Azure/GCS discriminator. While properly >> modeling the subtypes would be more faithful to the specification, it >> diverges from the existing pattern, so I opted for local consistency. I am >> happy to rework this if the project prefers to change the current pattern. >> >> I have verified this end-to-end against Polaris 1.5.0 with a prefix-scoped >> remote. >> >> p.s. also, would it be possible for me to join the slack channel without @ >> apache.org email domain? I tried to join the slack channel, but I >> couldn't. >> >> Thanks for your time in advance! >> >> Yong-Jin Lee >> Senior Data Engineer >> 1-703-999-9402 >> >
