Antalya 26.1 : Fix Alter table operations(add, modify, drop, rename) support for Iceberg#1594
Antalya 26.1 : Fix Alter table operations(add, modify, drop, rename) support for Iceberg#1594subkanthi wants to merge 8 commits intoantalya-26.1from
Conversation
|
…d columns to a separate function, added unit tests
|
|
||
| void assertInitializedDL() const | ||
| { | ||
| BaseStorageConfiguration::assertInitialized(); |
There was a problem hiding this comment.
This was removed in upstream
|
Testing: |
|
@codex review |
|
To use Codex here, create a Codex account and connect to github. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f344d72b29
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Poco::JSON::Array::Ptr identifier_fields = new Poco::JSON::Array; | ||
| schema_for_rest->set("identifier-field-ids", identifier_fields); | ||
| } |
There was a problem hiding this comment.
Preserve identifier-field-ids when sending schema updates
Overwriting identifier-field-ids with an empty array discards any existing row identity configuration for tables created outside ClickHouse. In buildUpdateMetadataRequestBody, schema_for_rest is cloned from the new schema but then unconditionally reset, so an ALTER against a REST-catalog Iceberg table with non-empty identifier fields will silently clear them in the committed schema update. This can break downstream equality-delete/merge workflows that depend on those IDs.
Useful? React with 👍 / 👎.
| if (!catalog->updateMetadata(namespace_name, table_name, catalog_filename, metadata)) | ||
| { | ||
| LOG_WARNING(log, "Iceberg alter: catalog update failed for '{}'", catalog_filename); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Do not retry by reapplying ALTER after failed catalog commit
After successfully writing the new metadata file, a catalog commit failure currently does continue, which re-enters the loop and applies the same alter operation again on top of already-updated metadata. For ADD COLUMN, this path can produce duplicate field entries (the add generator does not guard against existing names), and for other operations it can cause spurious failures because the first write already changed the schema version. This failure mode is triggered whenever updateMetadata returns false after a successful metadata write (e.g., transient REST error).
Useful? React with 👍 / 👎.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fixes Alter table ADD/DROP/RENAME/MODIFY column for Iceberg tables.
Documentation entry for user-facing changes
Solved ClickHouse#86024.
Fixed logic of updating metadata JSON as per Iceberg REST API Spec.
Added unit/integration tests.
CI/CD Options
Exclude tests:
Regression jobs to run: