Mike Drob created HBASE-19160:
---------------------------------

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

Reply via email to