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

stack commented on HBASE-13373:
-------------------------------

bq. Are you aiming for 1.1 or 2.0?

1.1 would be nice unless objection. Would be pain otherwise for patches that 
are messing in this area doing two versions (especially when functionality 
might span a V3, a V2, and the Abstract implementation).

bq. Could you try an upgrade from an instance of 0.98 with data?

Just did. Had to make changes to accommodate files with major version 2; made 
the version check a little sloppier.  Interesting area was encryption key from 
trailer but since it is pb'd and encryption key is allowed be null we should be 
good (we will fail if the hfile is not of the minor version that had pb).

Thanks too for nice review over on rb.  Next patch addresses your comments 
there and it makes it so can read 0.98 hfiles.  Thanks.



> Squash HFileReaderV3 together with HFileReaderV2 and AbstractHFileReader; 
> ditto for Scanners and BlockReader, etc.
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-13373
>                 URL: https://issues.apache.org/jira/browse/HBASE-13373
>             Project: HBase
>          Issue Type: Task
>            Reporter: stack
>            Assignee: stack
>         Attachments: 13373.txt, 13373.v3.txt, 13373.v3.txt, 13373.wip.txt
>
>
> Profiling I actually ran into case where complaint that could not inline 
> because:
> MaxInlineLevel maximum number of nested calls that are inlined 9 intx
> i.e. method was more than 9 levels deep.
> The HFileReaderV? with Abstracts is not needed anymore now we are into the 
> clear with V3 enabled since hbase 1.0.0; we can have just an Interface and an 
> implementation.  If we need to support a new hfile type, can hopefully do it 
> in a backward compatible way now we have Cell Interface, etc.
> Squashing all this stuff together actually makes it easier figuring what is 
> going on when reading code. I can also get rid of a bunch of duplication too.
> Attached is a WIP. Doesn't fully compile yet but you get the idea.
> I'll keep on unless objection. Will try it against data written with old 
> classes as soon as I have something working. I don't believe we write 
> classnames into our data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to