hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15296) Break out writer and reader from StoreFile
Date Mon, 11 Apr 2016 23:45:25 GMT

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

Hadoop QA commented on HBASE-15296:
-----------------------------------

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s {color} | {color:red}
HBASE-15296 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12798142/HBASE-15296-master-v2.patch
|
| JIRA Issue | HBASE-15296 |
| Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/1364/console |
| Powered by | Apache Yetus 0.2.1   http://yetus.apache.org |


This message was automatically generated.



> Break out writer and reader from StoreFile
> ------------------------------------------
>
>                 Key: HBASE-15296
>                 URL: https://issues.apache.org/jira/browse/HBASE-15296
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Appy
>            Assignee: Appy
>         Attachments: HBASE-15296-branch-1.1.patch, HBASE-15296-branch-1.2.patch, HBASE-15296-branch-1.patch,
HBASE-15296-master-v2.patch, HBASE-15296-master.patch
>
>
> StoreFile.java is trending to become a monolithic class, it's ~1800 lines. Would it make
sense to break out reader and writer (~500 lines each) into separate files.
> We are doing so many different things in a single class: comparators, reader, writer,
other stuff; and it hurts readability a lot, to the point that just reading through a piece
of code require scrolling up and down to see which level (reader/writer/base class level)
it belongs to. These small-small things really don't help while trying to understanding the
code. There are good reasons we don't do these often (affects existing patches, needs to be
done for all branches, etc). But this and a few other classes can really use a single iteration
of refactoring to make things a lot better.



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

Mime
View raw message