Skip to content

Add RealmConfig #2015

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add RealmConfig #2015

wants to merge 2 commits into from

Conversation

XN137
Copy link
Contributor

@XN137 XN137 commented Jul 9, 2025

getting a config value currently requires quite a ceremony:

ctx.getPolarisCallContext()
   .getConfigurationStore()
   .getConfiguration(ctx.getRealmContext(), "ALLOW_WILDCARD_LOCATION", false))

since a PolarisConfigurationStore cant be used without a RealmContext it makes sense to add a dedicated interface. this allows removal of verbose code and also moves towards injecting that interface via CDI at a request/realm scope in the future.

@XN137 XN137 force-pushed the add-PolarisRealmConfig branch from febcc48 to 201a495 Compare July 9, 2025 07:40
@XN137 XN137 marked this pull request as ready for review July 9, 2025 07:59
@XN137 XN137 changed the title add PolarisRealmConfig Add PolarisRealmConfig Jul 9, 2025
Copy link
Member

@snazy snazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this is a very nice improvement!

I'd just propose to not unnecessarily repeat "Polaris" in type names.

@XN137 XN137 changed the title Add PolarisRealmConfig Add RealmConfig Jul 9, 2025
@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jul 9, 2025
@eric-maynard
Copy link
Contributor

If we're making this change for ergonomic reasons, I don't think the new invocation is really ideal: x.getRealmConfig().getConfig(y). Is the return value of getRealmConfig the "config" or the return value of getConfig(y)? They both seem to claim they're fetching a config.

import jakarta.annotation.Nullable;
import org.apache.polaris.core.entity.CatalogEntity;

/** Realm-specific configuration used to retrieve runtime parameters. */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really a Realm-specific configuration? This looks more like a configuration store, like PolarisConfigurationStore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

depends on one's definition i guess, currently the interface allows retrieval of configuration values. in my book that makes it a "configuration".

do you want me to add "store" to the javadoc or to also rename the class? if the latter, any concrete name suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think calling it a RealmConfigurationStore would be a better name, but that also only makes me think more that this needs to be reconciled with PolarisConfigurationStore

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not mind the proposed renaming, but current name LGTM too.


public class RealmConfigImpl implements RealmConfig {

private final PolarisConfigurationStore configurationStore;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a new PolarisConfigurationStore implementation could achieve the same thing, we should try that approach first

Copy link
Contributor Author

@XN137 XN137 Jul 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the idea of having the interface is to make the life of the callers easier as they most often (/always?) operate in the context of a single realm / CallContext.

whether configuration values are stored by a single store for all/multiple realms or not is an implementation detail that callers should not care about.
so afaict PolarisConfigurationStore can keep its current implementation unless in the future we notice any advantages of "splitting it up".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whether configuration values are stored by a single store for all/multiple realms or not is an implementation detail that callers should not care about.

Isn't that a reason that you'd want to just inject a PolarisConfigurationStore rather than handling something called a RealmConfig?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PolarisConfigurationStore is essentially multi-realm (note its explicit realm method parameters). This class acts as a request-scoped facade to automatically contextualize request-specific config lookup with realm IDs and pass those calls to PolarisConfigurationStore.

Copy link
Contributor

@eric-maynard eric-maynard Jul 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm all for refactoring PolarisConfigurationStore to have both realm-agnostic and realm-gnostic (?) methods. But I do not think a new layer like this over the config store is necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new layer helps to properly delineate application-scoped data (PolarisConfigurationStore and/or it's config source) from request-scoped data (RealmConfig). Effectively, request-scoped code does not need to deal with explicit realm ID parameters, which, IMHO, is beneficial to code clarity and maintainability.

Copy link
Contributor

@eric-maynard eric-maynard Jul 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not having to deal with realms is definitely a great improvement, agreed. But my concern remains that this new class becomes the de facto “Polaris Configuration Store” and this redundancy does not improve clarity. Furthermore, the proposed structure could be interpreted as implying that these configs are set per-realm (while PolarisConfigurationStore confits are not) when in fact this is not the case.

@XN137
Copy link
Contributor Author

XN137 commented Jul 9, 2025

I don't think the new invocation is really ideal: x.getRealmConfig().getConfig(y). Is the return value of getRealmConfig the "config" or the return value of getConfig(y)? They both seem to claim they're fetching a config.

PolarisConfigurationStore.getConfiguration is also returning configuration values and not a configuration and certainly not a PolarisConfiguration (which is a parameter not a return value). 😅

but you are right, i also wasnt very convinced of the getConfig name, would you prefer getConfigValue or getValue or maybe just get? would any of those address your concern?

Copy link
Contributor

@dimas-b dimas-b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @XN137 ! The PR LGTM overall. I think it's a nice improvement in request/application-scoped delineation in the Polaris codebase.

@dimas-b
Copy link
Contributor

dimas-b commented Jul 10, 2025

@eric-maynard : are you ok with merging this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants