Re: [PR] OpenAPI: Add CatalogObjectIdentifier and CatalogObjectType schemas [iceberg]

["danielcweeks (via GitHub)" <gi...@apache.org>]

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: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org