Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Use of Realm Instead of RealmId #910

Open
flyrain opened this issue Jan 29, 2025 · 1 comment
Open

Proposal: Use of Realm Instead of RealmId #910

flyrain opened this issue Jan 29, 2025 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@flyrain
Copy link
Contributor

flyrain commented Jan 29, 2025

Describe the solution you'd like

I wanted to share my thoughts on the ongoing discussion in PR #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
  2. Configuring Polaris for Production
  3. 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.
@flyrain flyrain added the enhancement New feature or request label Jan 29, 2025
@flyrain flyrain added this to the 1.0.0 milestone Jan 29, 2025
@snazy
Copy link
Member

snazy commented Jan 29, 2025

We already have an ongoing discussion on the dev-mailing list - I'd really prefer to keep it in one place to not lose any history.

@flyrain flyrain modified the milestones: 1.0.0, 1.1.0 Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants