[
https://issues.apache.org/jira/browse/HBASE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383338#comment-14383338
]
Rajeshbabu Chintaguntla commented on HBASE-12975:
-------------------------------------------------
[~apurtell]
I am thinking more about split for APPROACH #3 at PHOENIX-1734. For index
column family store files we need to create both top and bottom reference files
irrespective of split key in the store file key range.
To support this we need to add splitStoreFile to SplitTransaction interface and
provide APIs to 1)create both top and bottom references irrespective of split
key in the store file key range 2) create top and/or bottom references based on
split key in the store file key range or not.
What do you say?
And also as stack mentioned here
https://issues.apache.org/jira/browse/HBASE-12975?focusedCommentId=14367729&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14367729
Instead of using SplitTransactionImpl directly It's better to use split
transaction implementation created from factory based on configuration.
> Supportable SplitTransaction and RegionMergeTransaction interfaces
> ------------------------------------------------------------------
>
> Key: HBASE-12975
> URL: https://issues.apache.org/jira/browse/HBASE-12975
> Project: HBase
> Issue Type: Improvement
> Reporter: Rajeshbabu Chintaguntla
> Assignee: Andrew Purtell
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-12975.patch, HBASE-12975.patch, HBASE-12975.patch
>
>
> Making SplitTransaction, RegionMergeTransaction limited private is required
> to support local indexing feature in Phoenix to ensure regions colocation.
> We can ensure region split, regions merge in the coprocessors in few method
> calls without touching internals like creating zk's, file layout changes or
> assignments.
> 1) stepsBeforePONR, stepsAfterPONR we can ensure split.
> 2) meta entries can pass through coprocessors to atomically update with the
> normal split/merge.
> 3) rollback on failure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
