Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 2 Nov 2017 20:40:00 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13115740.1509654621000.136522.1509655200336@Atlassian.JIRA>
In-Reply-To: <JIRA.13115740.1509654621000@Atlassian.JIRA>
References: <JIRA.13115740.1509654621000@Atlassian.JIRA> <JIRA.13115740.1509654621771@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-19160) Re-expose some CellUtil methods
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 02 Nov 2017 20:40:04 -0000


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

Mike Drob commented on HBASE-19160:
-----------------------------------

Part of the same issue also hid the CellComparator, which breaks Apache Hive's code. They are using CellComparator so that they can sort of List of Cells before writing it out for bulk load (an invariant given by us). They implement their own writers because they've got other magic going on, so I think a deep refactoring is out of scope.

I think we should provide an accessible CellComparator for folks to use, since the interface is Public, but there are no implementations available seems like a gap. MetaCellComparator staying private is good though.

> Re-expose some CellUtil methods
> -------------------------------
>
>                 Key: HBASE-19160
>                 URL: https://issues.apache.org/jira/browse/HBASE-19160
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0-alpha-4
>            Reporter: Mike Drob
>            Priority: Critical
>             Fix For: 2.0.0-beta-1
>
>
> On HBASE-18995 we moved a bunch of public methods to Private places. This inadvertently breaks donwstream consumers. Let's see if we can ease up on some of the lockdown and make life easier for them.
> Copying [~ram_krish]'s previous analysis:
> {quote}
> I read the Crunch projec't hbase-support related code. 
> -> It uses both CellUtil (Public exposed) and KeyValueUtil (@Private) classes for helper methods.
> -> All methods in CellUtil that are getting used are even now exposed in branch-2's CellUtil and they are very common helper methods. So we are safe here.
> -> Wrt KeyValueUtil the API is createFirstOnRow(). It is used in test cases and in some core code. In most of the places they are trying to create the splitKeys from the region's start keys and that is also getting persisted. I think here they can safely create a cell out of the given byte[] of the row.
> But there is one place where they are trying to do some scanning on a HFileScanner directly (@Private) scanner. So this should be changed because it is an internal interface for us. And on this scanner they have copied our seekTo() code into their source files for some scanning purpose. In this code they are actually using the KvUtil.createFirstOnRow() to seek to that first cell of that row.
> More over I think in branch-2 we are restricting even CPs from accessing some of our internal scanners and they can only use InternalScanner interface. So this code in crunch needs heavy refactoring to work with branch-2 in case they want to fit into the Public/Private exposed semantics that HBase presents to the downstreamers.
> -> If still they want some APIs like this we can expose CellUtil#createFirstOnRow, createLastOnRow, createFirstOnCol and createLastOnCol at the maximum. I think others are not useful and are more internal stuffs.
> {quote}


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)