flyrain opened a new issue, #910: URL: https://github.com/apache/polaris/issues/910
### Is your feature request related to a problem? Please describe. _No response_ ### Describe the solution you'd like I wanted to share my thoughts on the ongoing discussion in[ PR #741](https://github.com/apache/polaris/pull/741). about whether to use `Realm` or `RealmId`. The more I consider it, the more it seems that the name Realm is the natural choice. It is more an atomic concept, much like the concept of a `region` in AWS. If we take a closer look at the current usage across Polaris—in documentation, error messages, and configurations—`realm` and `realmId` are already used interchangeably. In fact, in most cases, we simply use `realm` rather than `realmId`. Here are a few examples in the Polaris repo: Error Messages: 1. `realm: <realm> root principal credentials: <client-id>:<client-secret>` Configurations: 1. `Polaris.realm-context.realms` 2. `jdbc:h2:file:./build/test_data/polaris/{realm}/db` Documentation: 1. [Metastores](https://polaris.apache.org/in-dev/unreleased/metastores/) 2. [Configuring Polaris for Production](https://polaris.apache.org/in-dev/unreleased/configuring-polaris-for-production/) 3. [Admin Tool](https://polaris.apache.org/in-dev/unreleased/admin-tool/) ## Proposal Based on this consistency and the conceptual clarity it brings, I proposed two options: - Option 1, using the name `realm` instead of `realmId` throughout Polaris and still keeping the interface (`public interface Realm`) for dependency injection purposes. The interface can be extensible in case we want to add any subconcept to the realm, which may never happen to be honest. - Option 2, purely using a string for `realm` instead of an interface, this is simpler ultimately, but not extensible and needs more effort to refactor the current code. Looking forward to hearing your thoughts on this. ### Describe alternatives you've considered _No response_ ### Additional context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
