laskoviymishka commented on code in PR #15750:
URL: https://github.com/apache/iceberg/pull/15750#discussion_r3585665879
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3734,6 +3734,50 @@ components:
type: array
items:
$ref: '#/components/schemas/StorageCredential'
+ labels:
+ $ref: '#/components/schemas/Labels'
+
+ Labels:
+ type: object
+ description: |
+ Catalog-provided metadata enrichment (for example ownership,
+ classification, or cost attribution) returned with a table or view.
+ Labels are ephemeral: catalog-owned, generated per request, and never
+ persisted to table metadata or versioned with table history. Optional;
+ clients may ignore them. Labels are catalog-specific; different
catalogs
+ may return different or no labels for the same object. `table` carries
+ entity-level labels; `columns` is an array of per-column entries, each
+ identifying its column by field-id.
+ properties:
+ table:
+ type: object
+ description: Top-level entity labels (attached to the catalog object
as a whole).
+ additionalProperties:
+ type: string
+ columns:
+ type: array
+ description: >-
+ Column-level labels. Each entry identifies its column by field-id.
+ items:
+ $ref: '#/components/schemas/ColumnLabels'
Review Comment:
I think there's a shape that satisfies both concerns here:
Keep a single `labels` field on LoadTableResult (nastra's point: one field
that carries the different label types, not multiple top-level fields). Inside
it, two optional sub-keys:
```
labels:
object: flat key-value, attached to the catalog object as a whole
fields: optional array, each entry field-id-keyed
```
That give the decoupling: object-level and field-level labels are separate,
and a column-less object (namespace) just carries `object` and omits `fields`,
without presupposing columns.
Two naming changes to make it general:
- `columns` -> `fields`, `ColumnLabels` -> `FieldLabels`, since the array is
field-id-keyed, not column-specific.
- keep the type named `Labels` (not `TabularLabels` or similar) so the same
type is reusable across tables/views/namespaces later. A field-specific name
would force a separate namespace type, which is the multi-type shape we're
trying to avoid.
So: one `labels` field, generic `Labels` type, optional `object` + `fields`
inside.
Namespace labels stay out of scope for this PR, but the shape leaves room
for them.
--
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]
