LuciferYang opened a new issue, #1011:
URL: https://github.com/apache/iceberg-cpp/issues/1011
## Summary
`TableMetadataBuilder::Impl::RemoveSchemas` filters `metadata_.schemas` but
never touches `schemas_by_id_`. Within the same builder the removed ids stay
resolvable, so `Build()` can produce metadata whose `current-schema-id` points
at a schema that is no longer in `schemas`.
## Root cause
`SetCurrentSchema` checks the id against `schemas_by_id_`, and the
current-schema check in `Build()` uses the same index. Both still find the
removed schema, so:
1. `RemoveSchemas({1})` followed by `SetCurrentSchema(1)` succeeds, and
`Build()` returns metadata with `current-schema-id: 1` while `schemas` no
longer contains schema 1.
2. `RemoveSchemas({1})` followed by `AddSchema` of the same schema finds it
through the stale index and skips re-adding it to `schemas`.
## Impact
`InMemoryCatalog::CommitTable` and `SqlCatalog::CommitTable` apply the
caller's update list on one builder, then `Build()` and write the result. A
commit carrying `[remove-schemas, set-current-schema]` for the same id is
enough to write that metadata file, and reading it back fails with `Cannot find
schema with current-schema-id=...`, so the table can no longer be loaded.
Java's `Builder.removeSchemas` does not update `schemasById` either, so this
is stricter than Java's builder.
## Proposed fix
Erase the removed ids from `schemas_by_id_` alongside the existing filter of
`metadata_.schemas`.
## Out of scope
`RemovePartitionSpecs` has the same gap with `specs_by_id_`. Follow-up.
--
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]
