Skip to content

Replace getConfiguration usage with PolarisCallContext to use RealmContext (PART 1) #1780

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

Merged
merged 2 commits into from
Jun 2, 2025

Conversation

gh-yzou
Copy link
Contributor

@gh-yzou gh-yzou commented Jun 2, 2025

getConfiguration should be called per RealmContext instead of per PolarisCallContext. In this PR #1758 we introduced new API to that passes RealmContext, instead. of PolarisCallContext.
This PR refactors all calls except the loadTasks to use the new API with RealmContext, instead of calling with PolarisCallContext.

Follow up PR to update the usage in loadTasks and completely remove the getConfiguration function that uses PolarisCallContext

@gh-yzou
Copy link
Contributor Author

gh-yzou commented Jun 2, 2025

@dimas-b @adutra i will need one more PR to be able to competely remove the usage of PolarisCallContext

Comment on lines -81 to +85
.flatMap(c -> Optional.ofNullable(c.getPolarisCallContext()))
.map(
pc ->
pc.getConfigurationStore()
.getConfiguration(pc, "ALLOW_WILDCARD_LOCATION", false))
ctx ->
ctx.getPolarisCallContext()
.getConfigurationStore()
.getConfiguration(ctx.getRealmContext(), "ALLOW_WILDCARD_LOCATION", false))
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this change?

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 so, because we need to "undo" the translation from CallContext to PolarisCallContext so that we can recover the RealmContext.

Copy link
Contributor

Choose a reason for hiding this comment

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

My bad, didn't notice there was a pc :-)

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jun 2, 2025
@flyrain flyrain enabled auto-merge (squash) June 2, 2025 23:43
@flyrain flyrain merged commit 5fe9fd9 into apache:main Jun 2, 2025
9 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Jun 2, 2025
* @param catalogEntity the catalog to check for an override
* @param config the configuration to load
* @return the current value set for the configuration key or null if not set
* @param <T> the type of the configuration value
*/
default <T> @Nonnull T getConfiguration(
PolarisCallContext ctx,
RealmContext realmContext,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: why not keep the old param name?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i think realmContext is a better parameter name that indicates clearly what the parameter is. "ctx" is very confusing by during the read of code like whether it is for CallContext or PolarisCallContext.

Assertions.assertEquals("entity-new3", store.getConfiguration(ctx, entity, cfg.apply(3)));
Assertions.assertEquals("entity-legacy4", store.getConfiguration(ctx, entity, cfg.apply(4)));
Assertions.assertEquals(
"test-default1", store.getConfiguration(testRealmContext, entity, cfg.apply(1)));
Copy link
Contributor

Choose a reason for hiding this comment

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

testRealmContext is not relevant here and does not affect the test's behaviour. I'd prefer to keep null.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sg! I will update this in my part 2 PR.

@dimas-b
Copy link
Contributor

dimas-b commented Jun 2, 2025

This PR is related to #1775

@dimas-b
Copy link
Contributor

dimas-b commented Jun 2, 2025

@flyrain : I would have appreciated a bit more review time given my involvement in #1758

@flyrain
Copy link
Contributor

flyrain commented Jun 2, 2025

Sorry for the auto-merging, hopefully the part 2 can address your comments. cc @gh-yzou.

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