IRC Events Endpoint Implementation: Server Side Catalog Handlers

[c-thiel]

Feature Request / Improvement

We have reached good consensus on the https://github.com/apache/iceberg/pull/12584. Before merging this new Endpoint to the REST Catalog Specification, we want to implement core classes.

This issue depends on https://github.com/apache/iceberg/issues/13580 and targets the implementation of Server Handlers for the new Endpoint /v1/{prefix}/events.

Query engine

None

Willingness to contribute

• [ ] I can contribute this improvement/feature independently
• [ ] I would be willing to contribute this improvement/feature with guidance from the Iceberg community
• [ ] I cannot contribute this improvement/feature at this time

[kevinjqliu]

Heres the relevant code for CatalogHandlers and RESTCatalogAdapter

Which will end up in the iceberg-rest-fixture image

[SarthakMeshram]

Hi, I’d like to work on this issue. I’ll review CatalogHandlers and RESTCatalogAdapter to implement the /v1/{prefix}/events handlers. Please confirm if tests in iceberg-rest-fixture are also in scope.

Thanks!

[AdamPurnomo]

From the spec, it says

Returns a sequence of changes to catalog objects (tables, namespaces, views) 
        that allows clients to efficiently track metadata modifications without polling individual 
        resources.

But looking around into the concrete implementations of the catalog, it doesn't seem that we do keep track of changes (audit trail) for each operation on catalog objects (namespace, view, table). Is the scope of this issue to also implement the part where we need to keep track the audit trail on catalog object for all catalog implementations? If it does, seems like we can split this issue into multiple smaller issues.

[c-thiel]

Is the scope of this issue to also implement the part where we need to keep track the audit trail on catalog object for all catalog implementations? If it does, seems like we can split this issue into multiple smaller issues.

No, a simple in-memory implementation for the test harness is enough. This issue is not meant to solve it for all implementations.

[AdamPurnomo]

Cool, I am up for contribution, but this will need to wait until the core object PR is merged