Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

View does not expose metadata_location: RestCatalog.load_view discards it from the server's response

Open Beginner friendly
#4,073 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Soumo-git-hub is already working on this.

Since Oct 7, 2026.

  • #4088 by @Soumo-git-hub — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
api, databases

Research direction

Start in pyiceberg/catalog/rest/init.py at _response_to_view, comparing it with _response_to_table and the ViewResponse model. Verify that load_view and create_view preserve the REST metadata-location value and that the resulting View exposes it for the register_view use case described in the issue.

Written by the indexing model from the issue text.

Description

kind:bug
Apache Iceberg version

0.12.0 (latest release)

Please describe the bug 🐞

RestCatalog.load_view (and create_view) parse the server's metadata-location but drop it when building the View, so callers cannot learn where a view's current metadata file is. Tables keep it as Table.metadata_location; views have no equivalent. The behaviour is unchanged on main.

The spec (open-api/rest-catalog-open-api.yaml) requires the field in every view load result:

LoadViewResult:
  required:
    - metadata-location
    - metadata

with the description: "The corresponding file location of view metadata is returned in the metadata-location field. Clients can check whether metadata has changed by comparing metadata locations after the view has been created."

pyiceberg parses it, then discards it (pyiceberg/catalog/rest/__init__.py on main):

class ViewResponse(IcebergBaseModel):
    metadata_location: str | None = Field(alias="metadata-location", default=None)
    metadata: ViewMetadata
    config: Properties = Field(default_factory=dict)

def _response_to_view(self, identifier_tuple, view_response: ViewResponse) -> View:
    return View(
        identifier=identifier_tuple,
        metadata=view_response.metadata,
        config=view_response.config,
    )   # view_response.metadata_location is never passed on

_response_to_table, by contrast, passes metadata_location=table_response.metadata_location to Table.

Why it matters: without it, a client cannot detect changes to a view the way the spec suggests (comparing metadata locations), record where a view's metadata lives, or re-register a view from that file later with register_view.

Expected: View exposes metadata_location, set from the REST response, like Table.metadata_location.

PR #3390 ("REST: Add metadata_location to View, and register_view integration test") addressed this but was closed unmerged. Related umbrella issue: #818.

Willingness to contribute
  • I can contribute a fix for this bug independently
  • I would be willing to contribute a fix for this bug with guidance from the Iceberg community
  • I cannot contribute a fix for this bug at this time
Dominant language
Python
Stars
1.2k
Forks
618
Avg merge
1d 18h
Merged PRs (30d)
70

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/iceberg-python

All issues in apache/iceberg-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.