[
https://issues.apache.org/jira/browse/PHOENIX-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006928#comment-16006928
]
James Taylor commented on PHOENIX-3827:
---------------------------------------
Had an offline conversation with [~rajeshbabu] - the test changes are necessary
in the case where we're testing a local index becoming out of sync with the
data table. Since this is no longer possible, these tests should either be
adapted. If possible, it'd be good to adapt these tests (similar to what we did
when the table is transactional) to confirm that the local index remains in
sync with the data table (even across these kinds of failures). You might be
able to just piggyback on the checks we do for {{isTransactional}} and change
to {{isTransactional || isLocalIndex}}.
As far as the OnDuplicateKeyIgnoreIT, I'm not sure why those are failing. When
the ON DUPLICATE KEY syntax is used, these mutations come in through the
preIncrementAfterRowLock hook as Increment from the the client side. In this
hook, we transform the Increment to the Put/Delete mutations instead (after
applying the ON DUPLICATE KEY logic) and call region.mutateRowsWithLocks
(because we know the changes will all be region local). That should invoke the
regular secondary index code path - the data table mutations should just
generate the index table mutations. Any reason why this would be different for
local indexes?
> Make use of HBASE-15600 to write local index mutations along with data
> mutations atomically
> -------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3827
> URL: https://issues.apache.org/jira/browse/PHOENIX-3827
> Project: Phoenix
> Issue Type: Bug
> Reporter: Rajeshbabu Chintaguntla
> Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3827.patch, PHOENIX-3827_v2.patch
>
>
> After HBASE-15600 we can add mutations of the same table from coprocessors so
> we can write local index data along with data mutations so it will be atomic.
> This we can do in 4.x-HBase-1.3 version.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
