hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12972) Region, a supportable public/evolving subset of HRegion
Date Sat, 21 Feb 2015 03:13:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329961#comment-14329961
] 

Andrew Purtell commented on HBASE-12972:
----------------------------------------

I've started work on this. The first patch will be for 0.98 since there is no version of Phoenix
(yet) ported to 1.0 or master.

I did look at master for a bit. Unfortunately there are some aspects of the Table interface
that don't play nicely with HRegion code: close() and getScanner() are different. The former
isn't a big deal but when RegionScanner needed to implement ResultScanner I stopped there.
Not that we can't do it, but what I've decided to do instead is lift the minimum up out of
HRegion into Region to support coprocessors in the HBase tree and Phoenix together.

I'm treating introduction of the Region interface as a singularity of sorts for coprocessors:
neither source nor binary compatibility will be maintained. I don't see the harm in a singularity,
HRegion isn't supported, that's the point of this work... to replace it with something that
is. :-) However, after there is a first workable patch if it's not too onerous to make addtional
changes that keep source or binary compatibility then we can do that. 

> 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.0.1, 1.1.0, 0.98.11
>
>
> 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)

Mime
View raw message