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] [Comment Edited] (HBASE-12972) Region, a supportable public/evolving subset of HRegion
Date Thu, 19 Mar 2015 23:40:39 GMT

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

Andrew Purtell edited comment on HBASE-12972 at 3/19/15 11:40 PM:
------------------------------------------------------------------

I would *really* rather not do it, because it involves most methods in RegionObserver, RegionServerObserver,
RegionServerServices, but it is possible to keep the methods that accept HRegion objects,
deprecate them, and print warnings if they are used. This would mean the master patch stays
as is but the branch-1 port would have up to a doubling of methods in some interfaces. As
[~busbey] pointed out in a comment above see [CoprocessHost#useLegacyMethod|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java#L573],
[CoprocesorHost#legacyWarning|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java#L631],
and their use in [RegionCoprocessorHost|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java#L131].
We'd do the same in RegionObserver and extend their use to more methods in RegionServerObserver.
I advocated for a clean break from 1.1+ but we can do that only in 2.0 and higher. But please
consider the amount of deprecated code this leaves around throughout all of 1.x as proposed,
and it only pushes the day of reckoning down the road until whenever we do a 2.0. Related,
until we have a 2.0 projects like Phoenix would have no reason to change. The way I read the
above pushing this out to 2.0 is exactly so Phoenix won't have to deal with this change until
2.0. Do I have that wrong? Remember, HRegion is private, we said it will always be private,
there's no appropriate use of these internals now that we have decided that.


was (Author: apurtell):
I would *really* rather not do it, because it involves most methods in RegionObserver, RegionServerObserver,
RegionServerServices, but it is possible to keep the methods that accept HRegion objects,
deprecate them, and print warnings if they are used. This would mean the master patch stays
as is but the branch-1 port would have up to a doubling of methods in some interfaces. As
[~busbey] pointed out in a comment above see [CoprocessHost#useLegacyMethod|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java#L573],
[CoprocesorHost#legacyWarning|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java#L631],
and their use in [RegionCoprocessorHost|https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java#L131].
We'd do the same in RegionObserver and extend their use to more methods in RegionServerObserver.
I advocated for a clean break from 1.1+ but we can do that only in 2.0 and higher. But please
consider the amount of deprecated code this leaves around throughout all of 1.x as proposed,
and it only pushes the day of reckoning down the road until whenever we do a 2.0. Related,
until we have a 2.0 projects like Phoenix would have no reason to change. The way I read the
above pushing this out to 2.0 is exactly so Phoenix won't have to deal with this change until
2.0. Do I have that wrong?

> 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)

Mime
View raw message