c-thiel commented on code in PR #12584:
URL: https://github.com/apache/iceberg/pull/12584#discussion_r2112129175
##########
open-api/rest-catalog-open-api.py:
##########
@@ -1389,6 +1558,101 @@ class CommitTableResponse(BaseModel):
metadata: TableMetadata
+class EventsResponse(BaseModel):
+ next_page_token: Optional[PageToken] = Field(None, alias='next-page-token')
+ highest_processed_timestamp_ms: int = Field(
+ ...,
+ alias='highest-processed-timestamp-ms',
+ description='The highest timestamp processed by the server when
generating this response. This may not necessarily appear in the returned
changes if it was filtered out.\nClients can use this value as the
`after-timestamp-ms` parameter in subsequent requests to continue retrieving
changes after this point.\n',
+ )
+ events: List[Event]
+
+
+class Event(BaseModel):
+ event_id: str = Field(
+ ...,
+ alias='event-id',
+ description='Unique ID of this event. Clients should perform
deduplication based on this ID.',
+ )
+ request_id: str = Field(
+ ..., alias='request-id', description='ID of the request this change
belongs to.'
+ )
+ event_count: int = Field(
+ ...,
+ alias='event-count',
+ description='Number of events in the request / batch of events',
+ )
+ timestamp_ms: int = Field(
+ ...,
+ alias='timestamp-ms',
+ description='Timestamp when this transaction occurred (epoch
milliseconds). Timestamps are not guaranteed to be unique. Typically all events
in a transaction will have the same timestamp.\n',
+ )
+ actor_chain: Optional[List[Actor]] = Field(
+ None,
+ alias='actor-chain',
+ description='An ordered list of actors involved in the operation, with
the most direct actor (the one who actually performed the operation) first,
followed by delegating actors in order. For example, if a service account
(actor[0]) performed an operation on behalf of a role (actor[1]) assumed by a
user (actor[2]), the chain represents this delegation path.\n',
+ )
+ operation: Union[
+ CreateTableOperation,
+ RegisterTableOperation,
+ DropTableOperation,
+ UpdateTableOperation,
+ RenameTableOperation,
+ CreateViewOperation,
+ DropViewOperation,
+ ReplaceViewOperation,
+ CreateNamespaceOperation,
+ UpdateNamespacePropertiesOperation,
+ DropNamespaceOperation,
+ CustomOperation,
+ ] = Field(..., discriminator='operation_type')
+
+
+class CreateTableOperation(BaseModel):
+ operation_type: Literal['create-table'] = Field(
+ ..., alias='operation-type', const=True
+ )
+ identifier: TableIdentifier
+ table_uuid: UUID = Field(..., alias='table-uuid')
+ metadata: TableMetadata
+
+
+class RegisterTableOperation(BaseModel):
+ operation_type: Literal['register-table'] = Field(
+ ..., alias='operation-type', const=True
+ )
+ identifier: TableIdentifier
+ table_uuid: UUID = Field(..., alias='table-uuid')
+ metadata: TableMetadata
Review Comment:
Metadata is only returned for the initial `createTable` event. Other events
only contain incremental updates.
As this event is emitted at the time of table creation, TableMetadata is
typically quite short, so I don't see a big problem storing it. REST Catalogs
already store Metadata somewhere internally, and this is certainly one of the
smaller ones as it is the first in the lifecycle of the table.
Use-cases are outlined in the docs for this PR, I do see a value especially
for Federation & Workflow triggers.
--
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]
