[
https://issues.apache.org/jira/browse/PHOENIX-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239975#comment-16239975
]
Rajeshbabu Chintaguntla commented on PHOENIX-4323:
--------------------------------------------------
[~lhofhansl] [~jamestaylor]
bq. We can force the end-key to be higher somehow. We can also introduce a
split policy avoiding splitting regions between rows and index rows.
We are enforcing split key to be always data row key in IndexRegionSplitPolicy.
bq. Any thoughts on how to best prevent this? Can the split policy handle this?
We can change the split policy so that it returns region start key increment by
one when region start key is prefix to the original split key. But this also
might have corner cases like one here in the test case as well as if the all
the rows prefixed with region start key. So would be better to go by suffixing
empty byte arrays so that index row key never go beyond the region end key.
Will work on it if no one started working on it. Especially [~vincentpoon].
> LocalIndexes could fail if your data row is not in the same region as your
> index region
> ---------------------------------------------------------------------------------------
>
> Key: PHOENIX-4323
> URL: https://issues.apache.org/jira/browse/PHOENIX-4323
> Project: Phoenix
> Issue Type: Bug
> Reporter: churro morales
> Assignee: Vincent Poon
> Attachments: LocalIndexIT.java
>
>
> This is not likely to happen, but if this does your data table and index
> write will never succeed.
> In HRegion.doMiniBatchMutation()
> You create index rows in the preBatchMutate() then when you call checkRow()
> on that index row the exception will bubble up if the index row is not in the
> same region as your data row.
> Like I said this is unlikely, but you would have to do a region merge to fix
> this issue if encountered.
> [~vincentpoon] has a test which he will attach to this JIRA showing an
> example how this can happen. The write will never succeed unless you merge
> regions if this ever happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
