laskoviymishka commented on code in PR #15750:
URL: https://github.com/apache/iceberg/pull/15750#discussion_r3658726193
##########
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
Review Comment:
Agree here, that inheritance and attachment are real, well-defined concepts
in the catalogs that have a tag/entity model, and that's exactly why I'd keep
them out of this field.
Baking an attachment/inheritance model into the read path would force every
catalog to reason about it, including the simpler catalogs and engines that
have no such concept today. They'd end up with a more complicated story than
they need just to produce or consume a flat value.
So the intent here is the lowest common denominator: the catalog resolves
whatever it resolves (inheritance applied or not, its own way) and returns the
resolved values. A catalog with a rich tag model can still populate it; one
without doesn't have to grow one.
The structured side you're describing (attachment, inheritance provenance,
cross-catalog convergence) is important, but it's a heavier layer that should
build on top of this. I'm planning to expand into that as a follow-up (the
structured classification layer, see in original doc:
[here](https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit?tab=t.0#bookmark=id.oqyjwryl4lb)).
I plan to continue pushing this once simple read-path landed.
--
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]
