Skip to content

Conversation

@dimas-b
Copy link
Contributor

@dimas-b dimas-b commented Jun 9, 2025

Following up on #1555

  • Refactor pagination code to delineate API-level page tokens and
    internal "pointers to data"

  • Requests deal with the "previous" token, user-provided page size
    (optional) and the previous request's page size.

  • Concentrate the logic of combining page size requests
    and previous tokens in PageTokenUtil

  • PageToken subclasses are no longer necessary. EntityIdPaging handles
    pagination over ordered result sets with static helper methods.

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 the approach LGTM.

Some places however could be simplified and clarified though.

Copy link
Member

Choose a reason for hiding this comment

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

The function name and phrase 'from the previous API-level...are a bit confusing: what's "next"? What's "previous"? Why's there no "current"? All it does is constructing aPageRequest` from the two pagination-parameters.

Why not call this function constructFromParameters?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

refactored to PageToken.decode()... Is it better?

Copy link
Member

Choose a reason for hiding this comment

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

What's the general use case of this one? It's only used in some drop*() implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is now PageToken.fromLimit() (same name as before).

The use case is for handling initial paged requests where a size is provided, but a token in not. For API-based calls that is taken care of by the decode() method. This method is a convenience entry point for internal calls.

@dimas-b dimas-b changed the title Delineate pagination requests and tokens Persistence implementation for pagination in some requests Jun 10, 2025
@dimas-b
Copy link
Contributor Author

dimas-b commented Jun 10, 2025

Squashed, rebased, resolved conflicts and addressed some feedback. Please review again.

Following up on apache#1555

* Refactor pagination code to delineate API-level page tokens and
  internal "pointers to data"

* Requests deal with the "previous" token, user-provided page size
  (optional) and the previous request's page size.

* Concentrate the logic of combining page size requests
  and previous tokens in PageTokenUtil

* PageToken subclasses are no longer necessary. EntityIdPaging handles
  pagination over ordered result sets with static helper methods.

Co-authored-by: Eric Maynard <[email protected]>
if (pageToken.paginationRequested()) {
hql += " order by m.id asc";

if (pageToken.hasDataReference()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is still polymorphism, we're just not taking advantage of the fact that this is built into the language already:

if (pageToken isinstanceof EntityIdPageToken e) {
  tokenId = e.getEntityId();
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Polymorphism at the java type level is not necessary in this case. Users of the "data pointer" know how to parse it based on the API method called. It is not a matter of providing a sub-type, but about understanding the format.

Currently parsing is achieved via static methods in EntityIdPaging.

@github-actions
Copy link

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the Stale label Jul 14, 2025
snazy added a commit to snazy/polaris that referenced this pull request Jul 15, 2025
Based on apache#1838, following up on apache#1555

* Allows multiple implementations of `Token` referencing the "next page", encapsulated in `PageToken`. No changes to `polaris-core` needed to add custom `Token` implementations.
* Extensible to (later) support (cryptographic) signatures to prevent tampered page-token
* Refactor pagination code to delineate API-level page tokens and internal "pointers to data"
* Requests deal with the "previous" token, user-provided page size (optional) and the previous request's page size.
* Concentrate the logic of combining page size requests and previous tokens in `PageTokenUtil`
* `PageToken` subclasses are no longer necessary.
* Serialzation of `PageToken` uses Jackson serialization (smile format)

Since no (metastore level) implementation handling pagination existed before, no backwards compatibility is needed.

Co-authored-by: Dmitri Bourlatchkov <[email protected]>
Co-authored-by: Eric Maynard <[email protected]>
snazy added a commit that referenced this pull request Jul 16, 2025
Based on #1838, following up on #1555

* Allows multiple implementations of `Token` referencing the "next page", encapsulated in `PageToken`. No changes to `polaris-core` needed to add custom `Token` implementations.
* Extensible to (later) support (cryptographic) signatures to prevent tampered page-token
* Refactor pagination code to delineate API-level page tokens and internal "pointers to data"
* Requests deal with the "previous" token, user-provided page size (optional) and the previous request's page size.
* Concentrate the logic of combining page size requests and previous tokens in `PageTokenUtil`
* `PageToken` subclasses are no longer necessary.
* Serialzation of `PageToken` uses Jackson serialization (smile format)

Since no (metastore level) implementation handling pagination existed before, no backwards compatibility is needed.

Co-authored-by: Dmitri Bourlatchkov <[email protected]>
Co-authored-by: Eric Maynard <[email protected]>
@eric-maynard
Copy link
Contributor

IIUC #1938 supersedes this

@github-project-automation github-project-automation bot moved this from PRs In Progress to Done in Basic Kanban Board Jul 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants