[
https://issues.apache.org/jira/browse/HBASE-19160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238295#comment-16238295
]
stack commented on HBASE-19160:
-------------------------------
On below....
static CellComparator getInstance() {
You don't have to add the 'public' to the method because its in an Interface?
(All in an Interface is public even statics like this?) Good to know.
nit: If you have to make a new patch, I think you should add a warning on this
methods' javadoc "WILL NOT WORK FOR HBASE:META TABLE!!!!". I know you have
qualified with user space tables and that should be enough... but you might
have to hit folks w/ a hammer so they know not to try default CellCOmparator
against meta table This is a nit.
What we write into trailer on hfile now? CellComparatorImpl still?
Skimmed. Looks good to me.
> 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: 2.0.0-beta-1
>
> Attachments: HBASE-19160.patch, HBASE-19160.v2.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)
