[
https://issues.apache.org/jira/browse/HBASE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339746#comment-14339746
]
Sean Busbey commented on HBASE-12975:
-------------------------------------
If we make the LimitedPrivate Unstable for 1.0.z and then Evolving for 1.1.z+,
then we'd be fine. Quote from when this came up on HBASE-12972:
{quote}
bq. What if we marked Region LimitedPrivate / Unstable in 1.0.z?
Then why would someone use it? Region is supposed to be the supportable version
of HRegion. Unstable provides only effectively the same guarantees as
inappropriate use of Private interfaces.
{quote}
The reason to use it is that we'd label it Evolving or Stable in the next minor
release. We could even add a note in the javadoc explaining that it's Unstable
just to flag that folks have to keep in mind that it wasn't around at the start
of the API cut off for 1.0. Like the compat guide says, just because we have
the option to break things at a particular version (in this case at patches
sine it's Unstable) doesn't mean we will.
{quote}
I'd hope not, if perhaps only for this case. Otherwise we cannot extract
ourselves from this unfortunate situation until 1.1.0.
{quote}
Why don't we just plan to get 1.1.0 out the door in time for Phoenix 1.0? How
aggressive is the timeline?
> SplitTranaction, RegionMergeTransaction to should have InterfaceAudience of
> LimitedPrivate(Coproc,Phoenix)
> ----------------------------------------------------------------------------------------------------------
>
> Key: HBASE-12975
> URL: https://issues.apache.org/jira/browse/HBASE-12975
> Project: HBase
> Issue Type: Improvement
> Reporter: Rajeshbabu Chintaguntla
> Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.0.1, 1.1.0
>
> Attachments: 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)
