talatuyarer commented on code in PR #17966:
URL: https://github.com/apache/iceberg/pull/17966#discussion_r3984820665
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -661,6 +661,59 @@ paths:
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+ post:
+ tags:
+ - Catalog API
+ summary: Create a function in the given namespace
+ description:
+ Create a function in the given namespace.
+
+ The function is created with all of its definitions. The server
assigns `function-uuid`,
+ `format-version`, and `definition-log`, so those must not be sent in
the request.
+
+ operationId: createFunction
+ parameters:
+ - $ref: '#/components/parameters/idempotency-key'
+ requestBody:
+ required: true
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/schemas/CreateFunctionRequest'
+ responses:
+ 200:
+ $ref: '#/components/responses/LoadFunctionResponse'
+ 400:
+ $ref: '#/components/responses/BadRequestErrorResponse'
+ 401:
+ $ref: '#/components/responses/UnauthorizedResponse'
+ 403:
+ $ref: '#/components/responses/ForbiddenResponse'
+ 404:
+ description: Not Found - The namespace specified does not exist
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/schemas/IcebergErrorResponse'
+ examples:
+ NamespaceNotFound:
+ $ref: '#/components/examples/NoSuchNamespaceError'
+ 409:
+ description: Conflict - The function already exists
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/schemas/IcebergErrorResponse'
+ examples:
+ FunctionAlreadyExists:
+ $ref: '#/components/examples/FunctionAlreadyExistsError'
+ 419:
+ $ref: '#/components/responses/AuthenticationTimeoutResponse'
+ 503:
+ $ref: '#/components/responses/ServiceUnavailableResponse'
+ 5XX:
+ $ref: '#/components/responses/ServerErrorResponse'
+
/v1/{prefix}/namespaces/{namespace}/functions/{function}:
Review Comment:
With the current create/drop approach, the history is effectively reset
every time, which renders the definition-log transient rather than persistent.
I know updateFunction is planned as a follow-up, but it may be worth a note
(here or in the spec) that history/rollback semantics only become real once the
update endpoint lands
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -661,6 +661,59 @@ paths:
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+ post:
+ tags:
+ - Catalog API
+ summary: Create a function in the given namespace
+ description:
Review Comment:
These are plain scalars, so the blank line folds to a single \n and Swagger
render the two intended paragraphs as one run-on paragraph. `description: >`
preserves the paragraph break — that's what the file's other multi-paragraph
descriptions (e.g. planTableScan) use.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4964,6 +5078,41 @@ components:
metadata:
$ref: '#/components/schemas/FunctionMetadata'
+ CreateFunctionRequest:
Review Comment:
`CreateFunctionRequest` is ambiguous regarding field ownership, which will
indeed lead to implementation divergence.
we can clarify this by explicitly stating in the description that the server
normalizes these fields, similar to how we handle view versions in
`CreateViewRequest`. Would it be clearer to add a note explicitly stating that
the server ignores or replaces client-provided values for version IDs and
timestamps, or should we define a separate `CreateFunctionDefinition` schema
that excludes these fields to enforce this separation at the API level?
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -4964,6 +5078,41 @@ components:
metadata:
$ref: '#/components/schemas/FunctionMetadata'
+ CreateFunctionRequest:
+ description: |
Review Comment:
These are plain scalars, so the blank line folds to a single \n and Swagger
render the two intended paragraphs as one run-on paragraph. `description: >`
preserves the paragraph break — that's what the file's other multi-paragraph
descriptions (e.g. planTableScan) use.
--
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]
