[
https://issues.apache.org/jira/browse/HBASE-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370406#comment-14370406
]
stack commented on HBASE-12972:
-------------------------------
bq. However, if we have the same patch in branch-1, we might need yet another
branch in Phoenix.
I thought that this patch in branch-1 was the idea and that the 'yet another
branch' would actually be the Phoenix master branch and the way forward for all
future Phoenix releases; no more need to do a release per hbase version because
Andrew's work made it so Phoenix no longer needed to muck in our internals.
I spent a bunch of time reviewing Andrew's work because I had this
understanding (I've +1'd it for 1.1).
> Region, a supportable public/evolving subset of HRegion
> -------------------------------------------------------
>
> Key: HBASE-12972
> URL: https://issues.apache.org/jira/browse/HBASE-12972
> Project: HBase
> Issue Type: New Feature
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-12972-0.98.patch, HBASE-12972.patch,
> HBASE-12972.patch
>
>
> On HBASE-12566, [~lhofhansl] proposed:
> {quote}
> Maybe we can have a {{Region}} interface that is to {{HRegion}} is what
> {{Store}} is to {{HStore}}. Store marked with {{@InterfaceAudience.Private}}
> but used in some coprocessor hooks.
> {quote}
> By example, now coprocessors have to reach into HRegion in order to
> participate in row and region locking protocols, this is one area where the
> functionality is legitimate for coprocessors but not for users, so an
> in-between interface make sense.
> In addition we should promote {{Store}}'s interface audience to
> LimitedPrivate(COPROC).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
