Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 18 Aug 2014 23:11:18 +0000 (UTC)
From: "Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12734519.1408137663608.27707.1408403478955@arcas>
In-Reply-To: <JIRA.12734519.1408137663608@arcas>
References: <JIRA.12734519.1408137663608@arcas>
Subject: [jira] [Commented] (HBASE-11762) Record the class name of Codec in
 WAL header
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ted Yu commented on HBASE-11762:
--------------------------------

bq. ReaderBase still uses a string returned by initReader instead of the new context class
The above is consistent with what ProtobufLogReader does:
{code}
  protected String initReader(FSDataInputStream stream) throws IOException {
{code}
bq. initAfterCompression should take a context object instead of a string now?
initAfterCompression() method only needs Cell Codec class name - this is true for both ProtobufLogReader and SecureProtobufLogReader. Therefore the context is not needed.

> Record the class name of Codec in WAL header
> --------------------------------------------
>
>                 Key: HBASE-11762
>                 URL: https://issues.apache.org/jira/browse/HBASE-11762
>             Project: HBase
>          Issue Type: Task
>          Components: wal
>            Reporter: Ted Yu
>            Assignee: Ted Yu
>             Fix For: 1.0.0, 2.0.0, 0.98.6
>
>         Attachments: 11762-v1.txt, 11762-v2.txt, 11762-v4.txt, 11762-v5.txt
>
>
> In follow-up discussion to HBASE-11620, Enis brought up this point:
> Related to this, should not we also write the CellCodec that we use in the WAL header. Right now, the codec comes from the configuration which means that you cannot read back the WAL files if you change the codec.
> This JIRA is to implement the above suggestion.


--
This message was sent by Atlassian JIRA
(v6.2#6252)