c-thiel commented on code in PR #12584:
URL: https://github.com/apache/iceberg/pull/12584#discussion_r2593210133
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1795,6 +1795,61 @@ paths:
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+ /v1/{prefix}/events:
+ parameters:
+ - $ref: '#/components/parameters/prefix'
+ post:
+ tags:
+ - Catalog API
+ summary: Get events for changes to catalog objects
+ description: >
+ Returns a sequence of changes to catalog objects (tables, namespaces,
views)
+ that allows clients to efficiently track metadata modifications
without polling individual
+ resources. Consumers track their progress through a next-page-token,
enabling resumable
+ synchronization after downtime or errors.
+
+ This endpoint primarily supports use cases like catalog federation,
workflow triggering,
+ and basic audit capabilities.
+
+ When a request includes a `next-page-token`, it takes precedence over
Review Comment:
I think we are on the same page here :)
> So if there 100 clients using 100 different filters, the catalog server
would need to maintain 100 different changelog feeds?
Catalogs that don't have a global sequence will need to find a solution if
they want to support the endpoint, yes.
> But if a catalog has some global sequence number for ordering, it is a
perfect fit for the continuation token.
Yes exactly. Lakekeeper has a global sequence and we are going to use it.
Do you think any changes to the proposals result from our discussion (apart
from renaming pagination to continuation token)?
--
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]
