[ https://issues.apache.org/jira/browse/HBASE-19160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ted Yu updated HBASE-19160: --------------------------- Attachment: 19160.addendum Proposed addendum which fixes the compilation for hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java > Re-expose CellComparator > ------------------------ > > 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 > Assignee: Mike Drob > Priority: Critical > Fix For: 3.0.0, 2.0.0-beta-1 > > Attachments: 19160.addendum, HBASE-19160.patch, HBASE-19160.v2.patch, > HBASE-19160.v3.patch, HBASE-19160.v4.patch > > > 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)