jackye1995 commented on code in PR #9660:
URL: https://github.com/apache/iceberg/pull/9660#discussion_r1480039963
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -212,6 +212,34 @@ paths:
schema:
type: string
example: "accounting%1Ftax"
+ - name: pageToken
+ in: query
+ description:
+ Allows clients to make use of pagination by signaling to the
service that they would
+ prefer requests to be paginated to a “reasonable” number of
results.
+
+ New Clients always start the request by sending a required empty
“pageToken” e.g. GET /tables?continuationToken=””
+ Servers supporting pagination would recognize pagination is
requested due to the presence of the pageToken
+ and honor the contracts specified above by returning a non-empty
continuation token
+ if there are more results available, or an empty token or missing
field indicating no more results.
+ Servers that are non-pagination aware will ignore the token and
return all results as they previously did.
+
+ Old clients should not be specifying the new parameters
+ For servers that support pagination, they would notice the lack of
“continuationToken”
Review Comment:
So suppose we don't have empty page token, and service chooses what to do,
either return full results or paginate. This means the old Iceberg REST clients
will return incomplete results, seems like that is the issue.
On the other side, if we choose the token approach, we will also need a
feature flag in the REST integrations, to use pagination or not. If the feature
is turned off, then some REST services might run out of time before returning
all contents, and have to fail the request. If the feature is turned on, then
both REST services that support pagination or not can return full results.
Yes in that case I agree your approach is definitely more backwards
compatible, but it is also cumbersome to even add a feature flag just for
pagination. Let's see what others think.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
