Writing v3 Table Metadata #3551
Conversation
ebyhr
left a comment
ebyhr
left a comment
There was a problem hiding this comment.
Does it make sense to add an integration test that Spark reads v3 tables written by PyIceberg?
abnobdoss
left a comment
abnobdoss
left a comment
There was a problem hiding this comment.
This is awesome - I'm excited for v3 table write support! Left a few minor comments; apologies if I misunderstood anything here.
| INITIAL_SPEC_ID = 0 | ||
| DEFAULT_SCHEMA_ID = 0 | ||
|
|
||
| SUPPORTED_TABLE_FORMAT_VERSION = 2 |
There was a problem hiding this comment.
Does this need to change?
There was a problem hiding this comment.
Does this PR only allow new v3 tables or does it also enable v1/v2 tables to be upgraded to v3?
| next_row_id: int | None = Field(alias="next-row-id", default=None) | ||
| """A long higher than all assigned row IDs; the next snapshot's `first-row-id`.""" | ||
|
|
||
| def model_dump_json(self, exclude_none: bool = True, exclude: Any | None = None, by_alias: bool = True, **kwargs: Any) -> str: |
There was a problem hiding this comment.
Is row lineage fully wired up? If I'm not mistaken, row lineage would be a pre-requisite for v3 enablement?
|
The v3 spec marks |
Allow upgrade_table_version(3) and initialize next-row-id to 0 on upgrade, per the spec's Row Lineage for Upgraded Tables. Persisting the upgraded metadata still requires V3 metadata serialization (apache#3551). Closes apache#3622 Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Allow upgrade_table_version(3) and initialize next-row-id to 0 on upgrade, per the spec's Row Lineage for Upgraded Tables. Persisting the upgraded metadata still requires V3 metadata serialization (apache#3551). Closes apache#3622
| """A long higher than all assigned row IDs; the next snapshot's `first-row-id`.""" | ||
|
|
||
| def model_dump_json(self, exclude_none: bool = True, exclude: Any | None = None, by_alias: bool = True, **kwargs: Any) -> str: | ||
| raise NotImplementedError("Writing V3 is not yet supported, see: https://github.com/apache/iceberg-python/issues/1551") |
There was a problem hiding this comment.
One edge case this change surfaces: the v3 spec allows an optional encryption-keys list in table metadata, and the Java TableMetadataParser writes it when present. PyIceberg doesn't model the field, and the pydantic models ignore unknown fields, so it's dropped at parse time. With serialization enabled, loading a v3 table that carries encryption-keys and committing any update would rewrite the metadata without the keys, which would break an encrypted table. Would it make sense to add a passthrough encryption-keys field to TableMetadataV3 so it round-trips, even before encryption is actually supported?
4 participants
Rationale for this change
We're far enough into v3 (with a ratified spec!) that we should consider writing v3 table metadata.
Are these changes tested?
Added a unit test and fixed up the places where we were expecting errors
Are there any user-facing changes?