laskoviymishka commented on code in PR #15750:
URL: https://github.com/apache/iceberg/pull/15750#discussion_r3658791073


##########
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

Review Comment:
   Agree here, but I don't think we could solve this on the read path. 
   
   Stable identity across rename (so a consumer that bound a `PII` policy to a 
synced label can reconcile when the value or name changes) is an entity 
property. It needs a first-class tag with its own id and lifecycle, which is 
the structured write layer, not a flat resolved read value.
   
   Adding a `uuid` to this field would pull that entity model onto the read 
path, which is exactly the flat-vs-structured line I'm trying to keep clean. So 
rather than half-modeling it here, I'd carry it as a first-class part of the 
structured classification layer (design doc 
[here](https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit?tab=t.0#bookmark=id.oqyjwryl4lb)),
 which calls out stable identity and rename/delete lifecycle explicitly.
   
   This is the case we went deep on offline and it's the main driver for the 
structured follow up track. 



-- 
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]

Reply via email to