[
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)
