Skip to content

REST spec: Add Optional UUID for Namespaces to OpenAPI spec#15317

Closed
talatuyarer wants to merge 3 commits intoapache:mainfrom
talatuyarer:rest-namespace-uuid
Closed

REST spec: Add Optional UUID for Namespaces to OpenAPI spec#15317
talatuyarer wants to merge 3 commits intoapache:mainfrom
talatuyarer:rest-namespace-uuid

Conversation

@talatuyarer
Copy link
Copy Markdown
Contributor

This PR adds an optional namespace-uuid to REST API namespace responses. This UUID uniquely identifies a namespace, allowing name reuse, and supports catalog synchronization. We discussed at last Catalog Sync.

Comment thread open-api/rest-catalog-open-api.py Outdated

class CreateNamespaceResponse(BaseModel):
namespace: Namespace
namespace_uuid: str | None = Field(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to put this under the Namespace itself as an optional field, similar to how it's done for TableMetadata/ViewMetadata. We will then most likely need a separate NamespaceParser that reads/writes that optional uuid. Right now we only have a NamespaceSerializer and NamespaceDeserializer which serDe the levels of the namespace directly

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good! I changed the spec accordingly. I added oneOf we can accept string array or NamespaceObject which has optional uuid field.

…how it's done for TableMetadata/ViewMetadata.
@talatuyarer
Copy link
Copy Markdown
Contributor Author

@nastra I've updated the spec and created a separate implementation PR for easier review. You can find the implementation here: #15408

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would leave the example in

type: string
example: [ "accounting", "tax" ]
oneOf:
- type: array
Copy link
Copy Markdown
Contributor

@nastra nastra Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe extract this out into a NamespaceArray schema type so that it can be reused here and further below

items:
type: string
example: [ "accounting", "tax" ]
oneOf:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it would be an incompatible change. We might need to consider a new endpoint to represent a new structure (e.g. a v2 list)

@github-actions
Copy link
Copy Markdown

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

@github-actions github-actions Bot added the stale label Apr 18, 2026
@github-actions
Copy link
Copy Markdown

This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

@github-actions github-actions Bot closed this Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants