adnanhemani commented on code in PR #12584: URL: https://github.com/apache/iceberg/pull/12584#discussion_r2113256999
########## 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: I've commented this under the RegisterTableOperation. I understand your point for CreateTableOperation, and I'm still not sure I see the use case for it - but I think it is certainly still possible to store. I'm in agreement that it should be of a small size. However, when registering an existing Iceberg table, it is possible that the table has already has a large table metadata size - and as a result, I don't think that is okay to store in a persistence for a catalog, personally. WDYT? I re-read the Federation and Workflow subsections of the use-case but it does not answer the question I posed above clearly - can you expand more on why having the `TableMetadata` on the `CreateTableOperation` and `RegisterTableOperation`, specifically, helps the Federation and Workflow use-cases? -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org