[
https://issues.apache.org/jira/browse/PHOENIX-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544578#comment-17544578
]
ASF GitHub Bot commented on PHOENIX-6719:
-----------------------------------------
gjacoby126 commented on code in PR #1448:
URL: https://github.com/apache/phoenix/pull/1448#discussion_r886070517
##########
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java:
##########
@@ -1532,23 +1538,26 @@ private PTable getTableFromCells(List<Cell>
tableCellList, List<List<Cell>> allC
long columnTimestamp =
columnCellList.get(0).getTimestamp() !=
HConstants.LATEST_TIMESTAMP ?
columnCellList.get(0).getTimestamp() : timeStamp;
+ boolean isSalted = saltBucketNum != null
Review Comment:
If we're doing an ALTER we need to check both the original version of the
table AND the Cells from the ALTER to see if the table's salted
> 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.7#820007)
