You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Kuan-Po Tseng (JIRA)" <ji...@apache.org> on 2018/07/02 02:54:00 UTC

[jira] [Commented] (HBASE-18201) add UT and docs for DataBlockEncodingTool

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

Kuan-Po Tseng commented on HBASE-18201:
---------------------------------------

Sorry, I gave the wrong explain. The probolm is in
{code:java}
baosBytes = baos.toByteArray();
{code}
Encoder ROW_INDEX_V1 write integer in outputStream while the others write integer in byte array(baosBytes), we should change code like this
{code:java}
baos.flush();
baosBytes = baos.toByteArray();
this.dataBlockEncoder.endBlockEncoding(encodingCtx, out, baosBytes);
if(this.encodingCtx.getDataBlockEncoding().equals(DataBlockEncoding.ROW_INDEX_V1)) {
  baosBytes = baos.toByteArray();
}{code}
Add baos.toByteArray() after endBlockEncoding again to make sure the integer writes in outputstream with Encoder ROW_INDEX_V1 dump to byte array (baosBytes).

The if branch is neccessary because Encoders excepts ROW_INDEX_V1 write integer in baosBytes directly, without if branch and do toByteArray() again, baosBytes won't contains the integer wrotten in endBlockEncoding.

> add UT and docs for DataBlockEncodingTool
> -----------------------------------------
>
>                 Key: HBASE-18201
>                 URL: https://issues.apache.org/jira/browse/HBASE-18201
>             Project: HBase
>          Issue Type: Sub-task
>          Components: tooling
>            Reporter: Chia-Ping Tsai
>            Assignee: Kuan-Po Tseng
>            Priority: Minor
>              Labels: beginner
>         Attachments: HBASE-18201.master.001.patch, HBASE-18201.master.002.patch, HBASE-18201.master.002.patch, HBASE-18201.master.003.patch
>
>
> There is no example, documents, or tests for DataBlockEncodingTool. We should have it friendly if any use case exists. Otherwise, we should just get rid of it because DataBlockEncodingTool presumes that the implementation of cell returned from DataBlockEncoder is KeyValue. The presume may obstruct the cleanup of KeyValue references in the code base of read/write path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)