Skip to content

Point to the original name when moving a column renamed in the same update - #4103

Open
David-Banquet wants to merge 1 commit into
apache:mainfrom
David-Banquet:move-renamed-column-error
Open

David-Banquet wants to merge 1 commit into
apache:mainfrom
David-Banquet:move-renamed-column-error

Conversation

@David-Banquet

Copy link
Copy Markdown

Closes #2599

Rationale for this change

Inside one update_schema(), move_first, move_before and move_after look names up in the schema as it was when the update started, plus columns added in the same update. A column renamed in the same update has to be moved by its original name. The Java SchemaUpdate.findForMove does the same, so this PR keeps the behavior.

What #2599 ran into is the error message: Cannot move missing column: renamed_column reads as if the rename was lost, which led to suspecting Glue consistency. As shown in the issue, it fails every time, on the SQL catalog as well as Glue.

When the missing name matches a pending rename, the error now says so:

ValueError: Cannot move missing column: y2 (renamed from y in this update, refer to it as y)

The same applies to the reference column of move_before and move_after. Other missing names keep the current message. The rename section of the API docs gets one sentence about it.

Are these changes tested?

Yes. test_move_renamed_column_by_new_name_points_to_original_name covers the three move methods, an unknown name (message unchanged), and moving by the original name after the rename. It fails without the change. The schema update tests in tests/test_schema.py and tests/table/test_init.py pass.

Are there any user-facing changes?

Only the error message, and the docs sentence.

…pdate

Moves resolve names against the base schema, as in Java, so moving a column by its pending
new name fails. Name the original column in the error and document it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Possible read-after-write consistency issue with multiple schema migration steps in Iceberg tables on AWS Glue + S3

1 participant