rraulinio opened a new issue, #1433:
URL: https://github.com/apache/iceberg-go/issues/1433
### Feature Request / Improvement
## Summary
This is a follow-up to #1360.
iceberg-go now has the foundation for SQL UDF catalog support:
- #1418 adds the spec-validated `udf` metadata model and metadata builder.
- #1432 adds the REST catalog read side for listing and loading functions.
The current Iceberg REST OpenAPI defines only the read-side function
operations:
- `GET /v1/{prefix}/namespaces/{namespace}/functions`
- `GET /v1/{prefix}/namespaces/{namespace}/functions/{function}`
The OpenAPI does not currently define standardized function write routes or
request/response contracts for operations such as create, replace/update, drop,
or commit. The REST spec change that introduced list/load support was
intentionally scoped as read-only Stage 1 and deferred function CRUD to a
follow-up proposal: https://github.com/apache/iceberg/pull/15180.
The `udf` metadata builder can construct valid immutable metadata, but a
REST client still needs a standardized catalog protocol for publishing that
metadata and atomically changing the catalog's current metadata pointer. Until
that protocol exists, iceberg-go should not introduce implementation-specific
REST routes or wire models that may diverge from the eventual Iceberg contract.
## Desired outcome
Once the Apache Iceberg REST catalog specification defines function write
operations, add the corresponding generic client support to iceberg-go using
the standardized contracts.
The implementation should, as applicable to the final specification:
- expose write operations through an optional catalog capability interface,
consistent with existing iceberg-go catalog patterns
- add the standardized endpoint constants and honor endpoint discovery
through `ConfigResponse.endpoints`
- implement the exact request and response wire models from the REST OpenAPI
- use the existing `udf` metadata model and builder rather than introducing
a second metadata representation
- preserve the specification's atomic metadata update and
overload/version-history semantics
- map standardized errors for missing namespaces/functions, already-existing
functions, conflicts, invalid requests, and unsupported operations
- implement any specified concurrency controls, preconditions, and
idempotency behavior
- add unit coverage for successful writes, validation failures, error
mapping, endpoint negotiation, concurrent/conflicting updates, and
round-tripping written metadata through `LoadFunction`
- add documentation and examples for the supported catalog operations
The public Go API should be designed from the final standardized operations
rather than assuming in advance that the REST surface will use a particular set
of create/replace/drop methods.
--
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]