[
https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227066#comment-16227066
]
ramkrishna.s.vasudevan commented on HBASE-18995:
------------------------------------------------
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.
> Move methods that are for internal usage from CellUtil to Private util class
> ----------------------------------------------------------------------------
>
> Key: HBASE-18995
> URL: https://issues.apache.org/jira/browse/HBASE-18995
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0-alpha-3
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18995-branch-2.002.patch,
> HBASE-18995-branch-2.patch, HBASE-18995-branch-2_1.patch,
> HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_1.patch,
> HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_2.patch,
> HBASE-18995_002-branch-2.patch, HBASE-18995_002-branch-2.patch,
> HBASE-18995_003-branch-2.patch, HBASE-18995_1.patch, HBASE-18995_2.patch,
> HBASE-18995_2.patch
>
>
> This was brought up long time back. We need to move some of the public APIs
> from CellUtil to internal private Util class because they are used in some
> internal flow and does not make sense to have it in a @public exposed Util
> class.
> The topic again came in HBASE-18945 RB comments also.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
