[ https://issues.apache.org/jira/browse/PHOENIX-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007387#comment-16007387 ]
James Taylor commented on PHOENIX-3825: --------------------------------------- +1. This makes sense, [~vincentpoon]. I filed PHOENIX-3847 to follow up. It seems to me that the code isn't handling out of order rows correctly. IMHO, we shouldn't even need the ignoreNewerMutations flag. If we let users handle the replay themselves (which will become the default after PHOENIX-3811), they have to submit failed batches in timestamp order. Ideally we should handle failed batches in any order (though the user definitely needs to supply the timestamp). > Mutable Index rebuild does not write an index version for each data row > version > ------------------------------------------------------------------------------- > > Key: PHOENIX-3825 > URL: https://issues.apache.org/jira/browse/PHOENIX-3825 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.10.0, 4.11.0 > Reporter: Vincent Poon > Assignee: Vincent Poon > Fix For: 4.11.0 > > Attachments: PHOENIX-3825.master.v1.patch > > > 1) Write a row > 2) Disable the index > 3) write a series of updates to the data row > 4) trigger the BuildIndexScheduleTask partial rebuild > The index table will only have 1 new version, whereas the data row had many > versions -- This message was sent by Atlassian JIRA (v6.3.15#6346)