Remove unused LIST_PAGINATION_ENABLED feature configuration #2296
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Why is this unused? |
Contributor
Author
I have no idea. It was introduced in #1528, that's all I know. |
Contributor
|
I think that this should have been used in #1938; does pagination now ignore this flag? |
Contributor
Author
dimas-b
approved these changes
Aug 12, 2025
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
Contributor
|
Adding if/else on the paginated call paths looks a bit of an overkill to me. As currently implemented, IIRC, pagination is controlled by the client. If the client does not request a call to be paginated, the server will work as before #1938. IMHO, the risk of breaking clients with current pagination code is low. |
Contributor
|
We have feature flags for tons of things controlled by the client -- like table location overlap, generic tables, drop-with-purge, policies, etc. This flag was put in place specifically to guard against regressions caused by the new code path introduced by pagination. |
Contributor
|
Fair point. I'll look into that presently. |
Contributor
Author
|
Moving this to draft while @dimas-b looks into this issue. |
dimas-b
added a commit
to dimas-b/polaris
that referenced
this pull request
Aug 19, 2025
The enforcement of the LIST_PAGINATION_ENABLED flag was missed in apache#1938. This change make the flag effective as discussed in apache#2296. Note: this causes a change in the default Polaris behaviour (no pagination by default) with respect to the previous state of `main`. However, there is no behaviour change with respect to 1.0.0 or 1.0.1 as previous releases did not have apache#1938.
Contributor
|
Following up in #2401 |
Contributor
Author
|
Closing then, thanks @dimas-b ! |
github-project-automation
bot
moved this from Ready to merge
to Done
in Basic Kanban Board
dimas-b
added a commit
that referenced
this pull request
Aug 20, 2025
The enforcement of the LIST_PAGINATION_ENABLED flag was missed in #1938. This change make the flag effective as discussed in #2296. Note: this causes a change in the default Polaris behaviour (no pagination by default) with respect to the previous state of `main`. However, there is no behaviour change with respect to 1.0.0 or 1.0.1 as previous releases did not have #1938.
dimas-b
added a commit
to dimas-b/polaris
that referenced
this pull request
Aug 20, 2025
The enforcement of the LIST_PAGINATION_ENABLED flag was missed in apache#1938. This change make the flag effective as discussed in apache#2296. Note: this causes a change in the default Polaris behaviour (no pagination by default) with respect to the previous state of `main`. However, there is no behaviour change with respect to 1.0.0 or 1.0.1 as previous releases did not have apache#1938.
dimas-b
added a commit
that referenced
this pull request
Aug 20, 2025
* feat: enforce LIST_PAGINATION_ENABLED The enforcement of the LIST_PAGINATION_ENABLED flag was missed in #1938. This change make the flag effective as discussed in #2296. Note: this causes a change in the default Polaris behaviour (no pagination by default) with respect to the previous state of `main`. However, there is no behaviour change with respect to 1.0.0 or 1.0.1 as previous releases did not have #1938.
snazy
added a commit
to snazy/polaris
that referenced
this pull request
Nov 20, 2025
* feat: enforce LIST_PAGINATION_ENABLED (apache#2401) * feat: enforce LIST_PAGINATION_ENABLED The enforcement of the LIST_PAGINATION_ENABLED flag was missed in apache#1938. This change make the flag effective as discussed in apache#2296. Note: this causes a change in the default Polaris behaviour (no pagination by default) with respect to the previous state of `main`. However, there is no behaviour change with respect to 1.0.0 or 1.0.1 as previous releases did not have apache#1938. * Add PolarisMetaStoreManager.loadEntities (apache#2290) * Add PolarisMetaStoreManager.loadEntities currently `PolarisMetaStoreManager.listEntities` only exposes a limited subset of the underlying `BasePersistence.listEntities` functionality. most of the callers have to post-process the `EntityNameLookupRecord` of `ListEntitiesResult` and call `PolarisMetaStoreManager.loadEntity` on the individual items sequentually to transform and filter them. this is bad for the following reasons: - suboptimal performance as we run N+1 queries to basically load every entity twice from the persistence backend - suffering from race-conditions when entities get dropped between the `listEntities` and `loadEntity` call - a lot of repeated code in all the callers (of which only some are dealing with the race-condition by filtering out null values) as a solution we add `PolarisMetaStoreManager.loadEntities` that takes advantage of the already existing `BasePersistence` methods. we rename one of the `listEntities` methods to `loadEntities` for consistency. since many callers dont need paging and want the result as a list, we add `PolarisMetaStoreManager.loadEntitiesAll` as a convenient wrapper. we also remove the `PolarisEntity.nameAndId` method as callers who only need name and id should not be loading the full entity to begin with. note we rework `testCatalogNotReturnedWhenDeletedAfterListBeforeGet` from `ManagementServiceTest` because the simulated race-condition scenario can no longer happen. * review: remove filter + transformer params * review: add TODO in listPolicies * review: improve javadoc * chore: fix Page javadoc (apache#2412) Correct method args (follow-up to apache#2401) * Add 1.0.1-incubating release blog post (apache#2403) * This change fixes: (apache#2395) * use dev@polaris.apache.org for announcement * publish Docker images only when the vote passed (we are not suppose to publish any public artifacts before the vote is completed) * update the vote email accordingly * remove blog post link in the release announcement email to let this to the discretion of the release manager * chore(deps): update actions/setup-java action to v5 (apache#2414) * chore(test): Restore PolarisAccessManager (apache#2413) Restore `PolarisAccessManager` (with default implementation of `IcebergTokenAccessManager`) which was added as an extension point for running Polaris tests in downstream build environments under apache#789, but was mistakenly removed in apache#2343 * Update changelog prior to 1.1.0 release (apache#2406) * fix(deps): update quarkus platform and group to v3.25.4 (apache#2279) * NoSQL: merge related changes * Last merged commit 82cd416 --------- Co-authored-by: Dmitri Bourlatchkov <dmitri.bourlatchkov@gmail.com> Co-authored-by: Christopher Lambert <xn137@gmx.de> Co-authored-by: JB Onofré <jbonofre@apache.org> Co-authored-by: Mend Renovate <bot@renovateapp.com> Co-authored-by: Pierre Laporte <pierre@pingtimeout.fr>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.