HIVE-29878: Support pagination for list endpoints in HMS REST Catalog and remove redundant type casting in REST Catalog

[Aggarwal-Raghav]

What changes were proposed in this pull request?

This PR updates HMSCatalogAdapter to correctly extract pageToken and pageSize query parameters for the listNamespaces, listTables, and listViews REST routes.
Additionally, this PR performs several architectural cleanups to modernize the adapter:

• Removed the redundant castResponse method, leveraging Java generics.
• Replaced the deprecated NAMESPACE_SPLITTER and decodeNamespace(String) with modern Iceberg 1.11.0 equivalents (namespaceFromQueryParam and decodeNamespace(..., "%1F")).
• Extracted 'pageToken', 'pageSize', and 'parent' string literals into standard constants.

Why are the changes needed?

Iceberg Rest Catalog Spec supports it as follows and this helps in catalog contains large number of tables.

1. https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L250-L269
2. https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L525-L538

Does this PR introduce any user-facing change?

NO

How was this patch tested?

Added TestHMSCatalogAdapterPagination JUnit test

[Aggarwal-Raghav]

CC @deniskuzZ , can you help with review?

[deniskuzZ]

can we extract pagination to decorator lambda or similar? need test

[Aggarwal-Raghav]

gentle ping for review @deniskuzZ , have handled your review comments.

[Aggarwal-Raghav]

Only listNamespaces, listTables, and listViews and listFunctions supports pagination based on iceberg spec.

[deniskuzZ]

could we apply minor changes to design, how about

/** Paging parameters of a list request; present only when the client sent pageSize. */
private record PageRequest(String token, String size) {
  static Optional<PageRequest> from(Map<String, String> vars) {
    return Optional.ofNullable(vars.get(PAGE_SIZE))
        .map(size -> new PageRequest(vars.get(PAGE_TOKEN), size));
  }
}

private static <R> R paginateIfRequested(
    Map<String, String> vars, Supplier<R> fullList, Function<PageRequest, R> page) {
  return PageRequest.from(vars).map(page).orElseGet(fullList);
}

usage

  private ListTablesResponse listTables(Map<String, String> vars) {
    Namespace namespace = namespaceFromPathVars(vars);
    return paginateIfRequested(vars,
        () -> CatalogHandlers.listTables(catalog, namespace),
        p -> CatalogHandlers.listTables(catalog, namespace, p.token(), p.size()));
  }

why did we need castResponse at all?

[Aggarwal-Raghav]

I kept castResponse because of original author's code. I think almost every return statement is wrapped with castResponse.

[deniskuzZ]

but is that actually needed? if not - we can drop it in follow-up PR

[Aggarwal-Raghav]

should I remove castRespose all together in this PR iteself?

[Aggarwal-Raghav]

but is that actually needed?

i don't think so.

[deniskuzZ]

should I remove castRespose all together in this PR iteself?

if that won't be a huge change, otherwise let's move it to follow-up. but drop it from pagination part of this PR

[Aggarwal-Raghav]

Removed castResponse in this PR and update PR title and description

[sonarqubecloud]

Quality Gate passed

Issues
23 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud