stevenzwu commented on code in PR #12584:
URL: https://github.com/apache/iceberg/pull/12584#discussion_r3357774814
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3708,6 +3778,74 @@ components:
allOf:
- $ref: '#/components/schemas/ScanTasks'
+ QueryEventsRequest:
+ type: object
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ A continuation token returned by a previous response. Clients
should treat the
+ token as an opaque value and pass it unmodified. If not provided,
events are
+ returned from the beginning of the event log subject to other
filters.
+ page-size:
+ type: integer
+ format: int32
+ minimum: 1
+ description: >
+ The maximum number of events to return in a single response.
+ If not provided, the server may choose a default page size.
+ Servers may return less results than requested for various
reasons, such as
+ server side limits, payload size or processing time.
+ since-timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ Optional starting timestamp (seek-to-timestamp) for the initial
request, in
+ milliseconds (inclusive). Lets clients begin consumption from a
rough point in time
Review Comment:
`Lets clients begin` seems incorrect syntactically. also a minor suggestion
for the sentence.
`The client consumes the events occurred since the specified timestamp. If
not provided, the full history is consumed.`
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4278,6 +4416,345 @@ components:
metadata:
$ref: '#/components/schemas/TableMetadata'
+ QueryEventsResponse:
+ type: object
+ required:
+ - continuation-token
+ - events
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ An opaque continuation token to fetch the next page of events.
+ This token encodes the server's cursor position and filter state.
+ Clients should treat this as an opaque value and pass it
unmodified in subsequent requests.
+ When no more events are currently available, the server returns an
empty `events` array
+ and a `continuation-token` that the client can re-issue later to
receive events that
+ occur after this point.
+ events:
+ type: array
+ items:
+ $ref: "#/components/schemas/Event"
+
+ Event:
+ type: object
+ required:
+ - event-id
+ - request-id
+ - request-event-count
+ - timestamp-ms
+ - operation
+ properties:
+ event-id:
+ type: string
+ description: Unique ID of this event. Clients should perform
deduplication based on this ID.
+ request-id:
+ description: >
+ Opaque ID of the request this change belongs to.
+ This ID can be used to identify events that were part of the same
request.
Review Comment:
`identify` doesn't seem to quite get the point. it is more like `to group
events`.
We explained the multi-event scenario in the `request-event-count`
description. We probably should pull some of the description here.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4278,6 +4416,345 @@ components:
metadata:
$ref: '#/components/schemas/TableMetadata'
+ QueryEventsResponse:
+ type: object
+ required:
+ - continuation-token
+ - events
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ An opaque continuation token to fetch the next page of events.
+ This token encodes the server's cursor position and filter state.
+ Clients should treat this as an opaque value and pass it
unmodified in subsequent requests.
+ When no more events are currently available, the server returns an
empty `events` array
+ and a `continuation-token` that the client can re-issue later to
receive events that
+ occur after this point.
+ events:
+ type: array
+ items:
+ $ref: "#/components/schemas/Event"
+
+ Event:
+ type: object
+ required:
+ - event-id
+ - request-id
+ - request-event-count
+ - timestamp-ms
+ - operation
+ properties:
+ event-id:
+ type: string
+ description: Unique ID of this event. Clients should perform
deduplication based on this ID.
+ request-id:
+ description: >
+ Opaque ID of the request this change belongs to.
+ This ID can be used to identify events that were part of the same
request.
+ type: string
+ request-event-count:
+ type: integer
+ description: >
+ Number of events produced by the originating catalog request (e.g.
updateTable
+ or commitTransaction) that generated this event. Such requests can
apply multiple
+ updates atomically, each surfaced as a separate event sharing the
same `request-id`;
+ this count reports how many events that originating request
produced in total.
+ timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ Timestamp when this event occurred (epoch milliseconds).
+ Timestamps are not guaranteed to be unique. Typically all events in
+ a transaction will have the same timestamp.
+ actor:
+ type: object
+ description: >
+ The actor who performed the operation, such as a user or service
account.
+ Implementations may add arbitrary additional fields; the optional
`id` field is
+ recommended as a portable identifier that consumers can render and
key on.
+ properties:
+ id:
+ type: string
+ description: >
+ Recommended, optional. Stable identifier of the actor (e.g. a
user or
+ service account). Provided when the server can attribute the
operation.
+ additionalProperties: true
Review Comment:
Recommend tightening this to `additionalProperties: type: string` to match
the rest of the spec.
Every extension-style map already in the spec is typed strings —
`Snapshot.summary`, namespace properties, table properties,
`StorageCredential.config`. `additionalProperties: true` here (along with
`custom-filters`) would be the only place in the spec where an extension map
admits arbitrary JSON values. Adding a second typing model creates an
inconsistency clients have to learn separately.
The recommended `id` field is already typed string, which is good. The
remaining open extension keys are where the divergence lives — and the use
cases articulated for actor (user / service account attribution) are all
string-shaped. Range / nested / non-string actor attributes haven't been
described as required.
If an implementation later genuinely needs richer structure under `actor`,
the same forward path that other extension maps take applies: graduate a typed
sub-field, or encode the structure in the string value. Neither requires
opening this slot to arbitrary JSON.
Same argument applies to `custom-filters` — flagged in a separate thread.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4278,6 +4416,345 @@ components:
metadata:
$ref: '#/components/schemas/TableMetadata'
+ QueryEventsResponse:
+ type: object
+ required:
+ - continuation-token
+ - events
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ An opaque continuation token to fetch the next page of events.
+ This token encodes the server's cursor position and filter state.
+ Clients should treat this as an opaque value and pass it
unmodified in subsequent requests.
+ When no more events are currently available, the server returns an
empty `events` array
+ and a `continuation-token` that the client can re-issue later to
receive events that
+ occur after this point.
+ events:
+ type: array
+ items:
+ $ref: "#/components/schemas/Event"
+
+ Event:
+ type: object
+ required:
+ - event-id
+ - request-id
+ - request-event-count
+ - timestamp-ms
+ - operation
+ properties:
+ event-id:
+ type: string
+ description: Unique ID of this event. Clients should perform
deduplication based on this ID.
+ request-id:
+ description: >
+ Opaque ID of the request this change belongs to.
+ This ID can be used to identify events that were part of the same
request.
+ type: string
+ request-event-count:
+ type: integer
+ description: >
+ Number of events produced by the originating catalog request (e.g.
updateTable
+ or commitTransaction) that generated this event. Such requests can
apply multiple
+ updates atomically, each surfaced as a separate event sharing the
same `request-id`;
+ this count reports how many events that originating request
produced in total.
+ timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ Timestamp when this event occurred (epoch milliseconds).
+ Timestamps are not guaranteed to be unique. Typically all events in
+ a transaction will have the same timestamp.
+ actor:
+ type: object
+ description: >
+ The actor who performed the operation, such as a user or service
account.
+ Implementations may add arbitrary additional fields; the optional
`id` field is
+ recommended as a portable identifier that consumers can render and
key on.
+ properties:
+ id:
+ type: string
+ description: >
+ Recommended, optional. Stable identifier of the actor (e.g. a
user or
+ service account). Provided when the server can attribute the
operation.
+ additionalProperties: true
+ operation:
+ description: >
+ The operation that was performed, such as creating or updating a
table.
+ The concrete type is selected by the `operation-type`
discriminator defined on
+ `BaseOperation`. Clients should discard events with unknown
operation types.
+ Operations are emitted only when the underlying change is
committed; staged changes
+ are not surfaced.
+ anyOf:
+ - $ref: "#/components/schemas/CreateTableOperation"
+ - $ref: "#/components/schemas/RegisterTableOperation"
+ - $ref: "#/components/schemas/DropTableOperation"
+ - $ref: "#/components/schemas/UpdateTableOperation"
+ - $ref: "#/components/schemas/RenameTableOperation"
+ - $ref: "#/components/schemas/CreateViewOperation"
+ - $ref: "#/components/schemas/DropViewOperation"
+ - $ref: "#/components/schemas/UpdateViewOperation"
+ - $ref: "#/components/schemas/RenameViewOperation"
+ - $ref: "#/components/schemas/CreateNamespaceOperation"
+ - $ref: "#/components/schemas/UpdateNamespacePropertiesOperation"
+ - $ref: "#/components/schemas/DropNamespaceOperation"
+
+ BaseOperation:
+ type: object
+ description: >
+ Base type for all catalog operations carried by an `Event`. The
`operation-type`
+ discriminator selects the concrete operation schema. Standard
operation types are
+ enumerated in `OperationType`. Implementation-specific operation types
use an `x-` prefix
+ (see `OperationType`) and are carried as a `BaseOperation` with
implementation-defined
+ additional properties; clients should discard operations with unknown
`operation-type`
+ values.
+ discriminator:
+ propertyName: operation-type
+ mapping:
+ create-table: "#/components/schemas/CreateTableOperation"
+ register-table: "#/components/schemas/RegisterTableOperation"
+ drop-table: "#/components/schemas/DropTableOperation"
+ update-table: "#/components/schemas/UpdateTableOperation"
+ rename-table: "#/components/schemas/RenameTableOperation"
+ create-view: "#/components/schemas/CreateViewOperation"
+ drop-view: "#/components/schemas/DropViewOperation"
+ update-view: "#/components/schemas/UpdateViewOperation"
+ rename-view: "#/components/schemas/RenameViewOperation"
+ create-namespace: "#/components/schemas/CreateNamespaceOperation"
+ update-namespace-properties:
"#/components/schemas/UpdateNamespacePropertiesOperation"
+ drop-namespace: "#/components/schemas/DropNamespaceOperation"
+ required:
+ - operation-type
+ properties:
+ operation-type:
+ $ref: "#/components/schemas/OperationType"
+
+ CreateTableOperation:
+ description: >
+ Operation to create a new table in the catalog.
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - table-uuid
+ - updates
+ properties:
+ operation-type:
+ type: string
+ const: "create-table"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ table-uuid:
Review Comment:
wondering if we should just call this `uuid` instead of `table-uuid` and
`view-uuid`. the operation-type already sets the context. but I am not strongly
about it.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4278,6 +4416,345 @@ components:
metadata:
$ref: '#/components/schemas/TableMetadata'
+ QueryEventsResponse:
+ type: object
+ required:
+ - continuation-token
+ - events
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ An opaque continuation token to fetch the next page of events.
+ This token encodes the server's cursor position and filter state.
+ Clients should treat this as an opaque value and pass it
unmodified in subsequent requests.
+ When no more events are currently available, the server returns an
empty `events` array
+ and a `continuation-token` that the client can re-issue later to
receive events that
+ occur after this point.
+ events:
+ type: array
+ items:
+ $ref: "#/components/schemas/Event"
+
+ Event:
+ type: object
+ required:
+ - event-id
+ - request-id
+ - request-event-count
+ - timestamp-ms
+ - operation
+ properties:
+ event-id:
+ type: string
+ description: Unique ID of this event. Clients should perform
deduplication based on this ID.
+ request-id:
+ description: >
+ Opaque ID of the request this change belongs to.
+ This ID can be used to identify events that were part of the same
request.
+ type: string
+ request-event-count:
+ type: integer
+ description: >
+ Number of events produced by the originating catalog request (e.g.
updateTable
+ or commitTransaction) that generated this event. Such requests can
apply multiple
+ updates atomically, each surfaced as a separate event sharing the
same `request-id`;
+ this count reports how many events that originating request
produced in total.
+ timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ Timestamp when this event occurred (epoch milliseconds).
+ Timestamps are not guaranteed to be unique. Typically all events in
+ a transaction will have the same timestamp.
+ actor:
+ type: object
+ description: >
+ The actor who performed the operation, such as a user or service
account.
+ Implementations may add arbitrary additional fields; the optional
`id` field is
+ recommended as a portable identifier that consumers can render and
key on.
+ properties:
+ id:
+ type: string
+ description: >
+ Recommended, optional. Stable identifier of the actor (e.g. a
user or
+ service account). Provided when the server can attribute the
operation.
+ additionalProperties: true
+ operation:
+ description: >
+ The operation that was performed, such as creating or updating a
table.
+ The concrete type is selected by the `operation-type`
discriminator defined on
+ `BaseOperation`. Clients should discard events with unknown
operation types.
+ Operations are emitted only when the underlying change is
committed; staged changes
+ are not surfaced.
+ anyOf:
+ - $ref: "#/components/schemas/CreateTableOperation"
+ - $ref: "#/components/schemas/RegisterTableOperation"
+ - $ref: "#/components/schemas/DropTableOperation"
+ - $ref: "#/components/schemas/UpdateTableOperation"
+ - $ref: "#/components/schemas/RenameTableOperation"
+ - $ref: "#/components/schemas/CreateViewOperation"
+ - $ref: "#/components/schemas/DropViewOperation"
+ - $ref: "#/components/schemas/UpdateViewOperation"
+ - $ref: "#/components/schemas/RenameViewOperation"
+ - $ref: "#/components/schemas/CreateNamespaceOperation"
+ - $ref: "#/components/schemas/UpdateNamespacePropertiesOperation"
+ - $ref: "#/components/schemas/DropNamespaceOperation"
Review Comment:
The `BaseOperation` and `Event.operation` descriptions promise something the
schema doesn't enforce, and the gap is worth closing on the prose side.
`BaseOperation` description currently reads:
> Implementation-specific operation types use an `x-` prefix ... and are
carried as a `BaseOperation` with implementation-defined additional properties;
clients should discard operations with unknown `operation-type` values.
But the schema: `Event.operation.anyOf` lists only the 12 concrete
operations (no `BaseOperation` branch), and `BaseOperation` doesn't declare
`additionalProperties: true`. A strict validator running against the schema
would reject `{"operation-type": "x-mycatalog.foo", ...}` even though the prose
says it should validate as a `BaseOperation`.
Looking at every other `anyOf` in the spec, the existing convention doesn't
make this kind of claim. `TableUpdate`, `ViewUpdate`, `TableRequirement`,
`MetricResult`, `ReportMetricsRequest` are all closed unions over known
concrete subtypes, no catch-all branch, no description text promising unknown
values validate. Even the patterns with explicitly open discriminator fields
(`BaseUpdate.action: type: string`, `BaseRequirement.type: type: string`) keep
`anyOf` closed; "open evolution" lives at the parser layer (Iceberg's
hand-written `XxxParser.fromJson` switches on the string and applications
dispatch from there), not at the schema layer.
Two routes to bring the events spec in line with that convention:
1. **Drop the over-promising sentences.** Remove the "are carried as a
`BaseOperation`" line from `BaseOperation`'s description and the "discard
events with unknown operation types" line from `Event.operation`'s description.
Match `TableUpdate`'s silence on the question — open-evolution becomes an
unstated parser-layer convention, exactly how `BaseUpdate` works today.
2. **Qualify the prose.** Keep the sentences but soften to make the
validation behavior implementation-defined, e.g. "Strict-validation behavior
for unknown `operation-type` values is implementation-defined; the typical
Iceberg pattern is for parsers to switch on `operation-type` and route unknown
values to a default handler."
Either keeps the spec internally consistent and consistent with the rest of
the union patterns. The current shape — description promising open evolution,
schema not delivering it — is the part that's off.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3405,6 +3490,101 @@ components:
allOf:
- $ref: '#/components/schemas/ScanTasks'
+ GetEventsRequest:
+ type: object
+ properties:
+ page-token:
+ $ref: "#/components/schemas/PageToken"
+ page-size:
+ type: integer
+ format: int32
+ description: >
+ The maximum number of events to return in a single response.
+ If not provided, the server may choose a default page size.
+ Servers may return less results than requested for various
reasons, such as
+ server side limits, payload size or processing time.
+ after-timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ The (server) timestamp in milliseconds to start consuming events
from (inclusive).
+ If not provided, the first available timestamp is used.
+ operation-types:
+ type: array
+ items:
+ $ref: "#/components/schemas/OperationType"
+ description: >
+ Filter events by the type of operation.
+ If not provided, all types are returned.
+ catalog-objects:
+ type: array
+ discriminator:
+ propertyName: reference-type
+ mapping:
+ namespace: "#/components/schemas/NamespaceReference"
+ table: "#/components/schemas/TableReference"
+ view: "#/components/schemas/ViewReference"
+ items:
+ oneOf:
+ - $ref: "#/components/schemas/NamespaceReference"
+ - $ref: "#/components/schemas/TableReference"
+ - $ref: "#/components/schemas/ViewReference"
+ description: >
+ List of catalog objects (namespaces, tables, views) to get events
for.
+ If not provided, events for all objects will be returned subject
to other filters.
+ For specified namespaces, events for the namespaces and all
containing objects
+ (namespaces, tables, views) will be returned.
+ custom-filters:
Review Comment:
The thread was originally resolved on the basis of restricting to
`additionalProperties: type: string` ("I added `type: string`" above).
[`7f17a42`](https://github.com/apache/iceberg/pull/12584/commits/7f17a42b4d274f495f6bb05c01f75e53145d8870)
widened it to `additionalProperties: true` without re-opening the discussion —
worth revisiting on its own.
Two reasons to restore the typed-string version:
1. **Every extension-style map already in the spec is typed strings.**
`Snapshot.summary`, namespace properties, table properties,
`StorageCredential.config` — none allow arbitrary JSON values.
`additionalProperties: true` on `custom-filters` would be the only such map in
the spec. The events endpoint doesn't have a stronger reason to diverge than
those did.
2. **The motivating use case is a string.** The example raised earlier on
this thread was filtering on `actor` (e.g. `actor=user-123`). That's a string.
Range queries, IN-clauses, and nested predicates haven't been described as
required for any concrete custom filter — the widening is for cases that aren't
articulated in the spec or the docs.
If a catalog later genuinely needs richer filter structure, the path forward
is the same as for any extension that outgrows the typed map: standardize a
dedicated typed filter (graduate out of the extension map), or encode the
structure in the string value (JSON-encoded, comma-separated lists). Both are
precedented; neither requires opening this slot to arbitrary JSON.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4278,6 +4416,345 @@ components:
metadata:
$ref: '#/components/schemas/TableMetadata'
+ QueryEventsResponse:
+ type: object
+ required:
+ - continuation-token
+ - events
+ properties:
+ continuation-token:
+ type: string
+ description: >
+ An opaque continuation token to fetch the next page of events.
+ This token encodes the server's cursor position and filter state.
+ Clients should treat this as an opaque value and pass it
unmodified in subsequent requests.
+ When no more events are currently available, the server returns an
empty `events` array
+ and a `continuation-token` that the client can re-issue later to
receive events that
+ occur after this point.
+ events:
+ type: array
+ items:
+ $ref: "#/components/schemas/Event"
+
+ Event:
+ type: object
+ required:
+ - event-id
+ - request-id
+ - request-event-count
+ - timestamp-ms
+ - operation
+ properties:
+ event-id:
+ type: string
+ description: Unique ID of this event. Clients should perform
deduplication based on this ID.
+ request-id:
+ description: >
+ Opaque ID of the request this change belongs to.
+ This ID can be used to identify events that were part of the same
request.
+ type: string
+ request-event-count:
+ type: integer
+ description: >
+ Number of events produced by the originating catalog request (e.g.
updateTable
+ or commitTransaction) that generated this event. Such requests can
apply multiple
+ updates atomically, each surfaced as a separate event sharing the
same `request-id`;
+ this count reports how many events that originating request
produced in total.
+ timestamp-ms:
+ type: integer
+ format: int64
+ description: >
+ Timestamp when this event occurred (epoch milliseconds).
+ Timestamps are not guaranteed to be unique. Typically all events in
+ a transaction will have the same timestamp.
+ actor:
+ type: object
+ description: >
+ The actor who performed the operation, such as a user or service
account.
+ Implementations may add arbitrary additional fields; the optional
`id` field is
+ recommended as a portable identifier that consumers can render and
key on.
+ properties:
+ id:
+ type: string
+ description: >
+ Recommended, optional. Stable identifier of the actor (e.g. a
user or
+ service account). Provided when the server can attribute the
operation.
+ additionalProperties: true
+ operation:
+ description: >
+ The operation that was performed, such as creating or updating a
table.
+ The concrete type is selected by the `operation-type`
discriminator defined on
+ `BaseOperation`. Clients should discard events with unknown
operation types.
+ Operations are emitted only when the underlying change is
committed; staged changes
+ are not surfaced.
+ anyOf:
+ - $ref: "#/components/schemas/CreateTableOperation"
+ - $ref: "#/components/schemas/RegisterTableOperation"
+ - $ref: "#/components/schemas/DropTableOperation"
+ - $ref: "#/components/schemas/UpdateTableOperation"
+ - $ref: "#/components/schemas/RenameTableOperation"
+ - $ref: "#/components/schemas/CreateViewOperation"
+ - $ref: "#/components/schemas/DropViewOperation"
+ - $ref: "#/components/schemas/UpdateViewOperation"
+ - $ref: "#/components/schemas/RenameViewOperation"
+ - $ref: "#/components/schemas/CreateNamespaceOperation"
+ - $ref: "#/components/schemas/UpdateNamespacePropertiesOperation"
+ - $ref: "#/components/schemas/DropNamespaceOperation"
+
+ BaseOperation:
+ type: object
+ description: >
+ Base type for all catalog operations carried by an `Event`. The
`operation-type`
+ discriminator selects the concrete operation schema. Standard
operation types are
+ enumerated in `OperationType`. Implementation-specific operation types
use an `x-` prefix
+ (see `OperationType`) and are carried as a `BaseOperation` with
implementation-defined
+ additional properties; clients should discard operations with unknown
`operation-type`
+ values.
+ discriminator:
+ propertyName: operation-type
+ mapping:
+ create-table: "#/components/schemas/CreateTableOperation"
+ register-table: "#/components/schemas/RegisterTableOperation"
+ drop-table: "#/components/schemas/DropTableOperation"
+ update-table: "#/components/schemas/UpdateTableOperation"
+ rename-table: "#/components/schemas/RenameTableOperation"
+ create-view: "#/components/schemas/CreateViewOperation"
+ drop-view: "#/components/schemas/DropViewOperation"
+ update-view: "#/components/schemas/UpdateViewOperation"
+ rename-view: "#/components/schemas/RenameViewOperation"
+ create-namespace: "#/components/schemas/CreateNamespaceOperation"
+ update-namespace-properties:
"#/components/schemas/UpdateNamespacePropertiesOperation"
+ drop-namespace: "#/components/schemas/DropNamespaceOperation"
+ required:
+ - operation-type
+ properties:
+ operation-type:
+ $ref: "#/components/schemas/OperationType"
+
+ CreateTableOperation:
+ description: >
+ Operation to create a new table in the catalog.
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - table-uuid
+ - updates
+ properties:
+ operation-type:
+ type: string
+ const: "create-table"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ table-uuid:
+ type: string
+ format: uuid
+ updates:
+ type: array
+ items:
+ $ref: "#/components/schemas/TableUpdate"
+
+ RegisterTableOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - table-uuid
+ properties:
+ operation-type:
+ type: string
+ const: "register-table"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ table-uuid:
+ type: string
+ format: uuid
+ updates:
+ type: array
+ items:
+ $ref: "#/components/schemas/TableUpdate"
+
+ DropTableOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - table-uuid
+ properties:
+ operation-type:
+ type: string
+ const: "drop-table"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ table-uuid:
+ type: string
+ format: uuid
+ purge:
+ type: boolean
+ description: Whether purge flag was set
+
+ UpdateTableOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - table-uuid
+ - updates
+ properties:
+ operation-type:
+ type: string
+ const: "update-table"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ table-uuid:
+ type: string
+ format: uuid
+ updates:
+ type: array
+ items:
+ $ref: "#/components/schemas/TableUpdate"
+ requirements:
+ type: array
+ items:
+ $ref: "#/components/schemas/TableRequirement"
+
+ RenameTableOperation:
+ allOf:
+ - $ref: "#/components/schemas/RenameTableRequest"
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - table-uuid
+ properties:
+ operation-type:
+ type: string
+ const: "rename-table"
+ table-uuid:
+ type: string
+ format: uuid
+
+ RenameViewOperation:
+ allOf:
+ - $ref: "#/components/schemas/RenameTableRequest"
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - view-uuid
+ properties:
+ operation-type:
+ type: string
+ const: "rename-view"
+ view-uuid:
+ type: string
+ format: uuid
+
+ CreateViewOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - view-uuid
+ - updates
+ properties:
+ operation-type:
+ type: string
+ const: "create-view"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ view-uuid:
+ type: string
+ format: uuid
+ updates:
+ type: array
+ items:
+ $ref: "#/components/schemas/ViewUpdate"
+
+ DropViewOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - view-uuid
+ properties:
+ operation-type:
+ type: string
+ const: "drop-view"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ view-uuid:
+ type: string
+ format: uuid
+
+ UpdateViewOperation:
+ allOf:
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
+ - operation-type
+ - identifier
+ - view-uuid
+ - updates
+ properties:
+ operation-type:
+ type: string
+ const: "update-view"
+ identifier:
+ $ref: "#/components/schemas/TableIdentifier"
+ view-uuid:
+ type: string
+ format: uuid
+ updates:
+ type: array
+ items:
+ $ref: "#/components/schemas/ViewUpdate"
+ requirements:
+ type: array
+ items:
+ $ref: "#/components/schemas/ViewRequirement"
+
+ CreateNamespaceOperation:
+ allOf:
+ - $ref: "#/components/schemas/CreateNamespaceResponse"
+ - $ref: "#/components/schemas/BaseOperation"
+ required:
Review Comment:
namespace identifier should also be required, right?
--
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]
