[
https://issues.apache.org/jira/browse/PHOENIX-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864143#comment-17864143
]
Istvan Toth edited comment on PHOENIX-6719 at 7/9/24 11:27 AM:
---------------------------------------------------------------
-This bug is present as far back as at least 5.0.-
-We should probably backport the fixt to the 5.1 branch.-
On second look, this bug seems to have been present on 5.0, which used
table.getColumns() to get the colums, but not on 5.1, which uses system.catalog
directly.
was (Author: stoty):
This bug is present as far back as at least 5.0.
We should probably backport the fixt to the 5.1 branch.
> Duplicate Salt Columns in Schema Registry after ALTER
> -----------------------------------------------------
>
> Key: PHOENIX-6719
> URL: https://issues.apache.org/jira/browse/PHOENIX-6719
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.2.0
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
> Fix For: 5.2.0
>
>
> When a table or view is change-detection enabled, we have to update the
> schema registry each time the schema is ALTERed. This is done by calculating
> the old PTable and applying the changed metadata edits to create a new
> PTable, which gets exported to the schema registry.
> There's a bug in this calculation logic for salted tables, where the virtual
> salt column is on the old PTable, but gets added by the Builder logic of the
> new PTable. The result is an incorrect PTable (and schema) with an extra salt
> column.
> I discovered this while testing on a draft of PHOENIX-5517.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
