danielcweeks commented on code in PR #16144:
URL: https://github.com/apache/iceberg/pull/16144#discussion_r3169903021
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2267,6 +2267,27 @@ components:
type: string
nullable: false
+ CatalogObjectIdentifier:
+ description:
+ Reference to a catalog object (table, view, or namespace) as an
+ ordered list of hierarchical levels.
+ The object kind is determined by context (e.g. the endpoint or a
+ companion CatalogObjectType discriminator), not by the identifier
+ structure alone.
+ type: array
+ items:
+ type: string
+ example: [ "accounting", "tax", "paid" ]
+
+ CatalogObjectType:
+ type: string
+ description: |
+ The type of a catalog object.
+ enum:
+ - table
+ - view
+ - namespace
Review Comment:
I think there was an open question about how and where this would actually
be used. Introducing `type` without context leaves me unsure if it's inline
with how we want to reference types.
For example, you could have the resolve endpoint return:
```yaml
[
[ identifier, type, metadata ]
[ identifier, type, metadata ]
...
]
```
or:
```yaml
tables: <identifier, metadata>
views: <identifier, metadata>
namespaces: <identifier, metadata>
```
The first approach requires `type`, but might impact backward compatibility.
If we introduce a new type (e.g. `function`) then clients would break if they
don't understand the type. The second approach allows you to extend the
response object without modifying the original fields.
I'd like to see how it would be referenced in context.
--
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]
