laskoviymishka commented on code in PR #15750:
URL: https://github.com/apache/iceberg/pull/15750#discussion_r3658769620
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3675,6 +3675,50 @@ components:
items:
$ref: '#/components/schemas/StorageCredential'
+ CatalogObjectLabels:
+ type: object
+ description: >-
+ Catalog-object-level labels, attached to the object (table, view, ...)
+ as a whole.
+ additionalProperties:
+ type: string
+
+ FieldLabels:
+ type: object
+ description: Labels attached to a single field, identified by field-id.
+ required:
+ - field-id
+ - labels
+ properties:
+ field-id:
+ type: integer
+ description: Field ID from the current schema of the table or view
+ labels:
+ type: object
+ description: Flat key-value labels for this field
+ additionalProperties:
+ type: string
+
+ Labels:
+ type: object
+ description: |
+ Catalog-provided metadata enrichment (for example ownership,
+ classification, or cost attribution) returned with a table or view.
+ Labels are generated per request and optional; clients may ignore them.
+ The spec does not require how a catalog produces or stores labels, nor
+ whether they are persisted or versioned. `object` carries
+ catalog-object-level labels; `fields` carries per-field labels, each
+ identified by field-id.
+ properties:
+ object:
+ $ref: '#/components/schemas/CatalogObjectLabels'
+ fields:
+ type: array
+ description: >-
+ Field-level labels. Each entry identifies its field by field-id.
Review Comment:
Every `field-id` is its own entry: the outer struct and the nested field are
two separate entries keyed by their own field-ids, so on the wire there's no
conflict to resolve. Both values are just carried as-is.
The question "which one wins" only comes up if you read a label as an
enforced access decision, and that's the part the spec deliberately doesn't
claim. `Labels` are informational; they don't carry precedence semantics. If a
catalog does derive an effective value across nested fields, that resolution
rule lives in the catalog and it can return the resolved value on the field-id
it applies to.
Defining precedence/interpretation in the spec would mean specifying a tag
model, which is the heavier structured layer I'd rather build on top as a
follow-up (design doc
[here](https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit?tab=t.0#bookmark=id.oqyjwryl4lb))
than bake into the read path here.
--
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]
