laskoviymishka commented on code in PR #18049:
URL: https://github.com/apache/iceberg/pull/18049#discussion_r4046532293
##########
spark/v4.1/spark/src/main/java/org/apache/iceberg/spark/source/BaseSparkTable.java:
##########
@@ -157,6 +162,23 @@ public Map<String, String> properties() {
.filter(entry -> !RESERVED_PROPERTIES.contains(entry.getKey()))
.forEach(propsBuilder::put);
+ // Surface catalog-provided labels (driver-side only; not part of table
state) so they are
+ // visible in DESCRIBE EXTENDED. The tbl.labels metadata table is the
queryable counterpart.
+ if (table instanceof SupportsLabels) {
+ Labels labels = ((SupportsLabels) table).labels();
+ labels
+ .objectLabels()
+ .forEach((key, value) -> propsBuilder.put(LABELS_OBJECT_PREFIX +
key, value));
Review Comment:
thx @szehon-ho, good catch, you're right that feeding both into one
ImmutableMap.Builder throws and breaks DESCRIBE EXTENDED / SHOW TBLPROPERTIES.
My thinking: labels and table properties are genuinely different concepts,
so ideally I'd surface catalog labels as their own section in DESCRIBE,
separate from Table Properties. But DescribeTableExec doesn't allow it - the
sections (schema, partitioning, metadata columns, detailed info, stats) are
hardcoded, each tied to a specific SPI method, and properties() is the only
channel a v2 connector has for arbitrary key-values (they all land in the
single Table Properties blob). A dedicated "Labels" field in DESCRIBE isn't
reachable from the connector side.
So as the pragmatic fallback I went with de-duplication, so neither is lost
and DESCRIBE never fails:
- a catalog label keeps its natural labels.object.<k> /
labels.field.<id>.<k> key when it's free;
- if a stored property already holds that key, the label is surfaced under a
de-conflicted ….catalog key (numeric suffix if that's also taken);
- the stored property always keeps its own key.
Both stay visible and build() can't throw. Added coverage for the object and
field prefixes.
For a properly separated, structured view, the queryable surface is the
tbl.labels metadata table (scope / field_id / field_name / key / value), that's
the authoritative place; the DESCRIBE properties are just at-a-glance
visibility.
--
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]
