hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
Date Wed, 19 Feb 2014 18:46:26 GMT

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

Andrew Purtell commented on HBASE-10531:
----------------------------------------

It would be great if we can do an exorcism of private interfaces rather than deprecate them.
We did this for KeyValue comparators between 0.96 and 0.98. I get that folks like Phoenix
want some measure of internal interface stability, but until 1.0 if the cost is adding technical
debt in the form of littering the code with half-broken or fully broken deprecated APIs, it
is not worth it. 

> Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
> ------------------------------------------------------------------------
>
>                 Key: HBASE-10531
>                 URL: https://issues.apache.org/jira/browse/HBASE-10531
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 0.99.0
>
>         Attachments: HBASE-10531.patch
>
>
> Currently the byte[] key passed to HFileScanner.seekTo and HFileScanner.reseekTo, is
a combination of row, cf, qual, type and ts.  And the caller forms this by using kv.getBuffer,
which is actually deprecated.  So see how this can be achieved considering kv.getBuffer is
removed.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message