[ https://issues.apache.org/jira/browse/HBASE-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217700#comment-13217700 ]
Phabricator commented on HBASE-5442: ------------------------------------ mbautin has committed the revision "[jira] [HBASE-5442] [89-fb] Use builder pattern in StoreFile and HFile". REVISION DETAIL https://reviews.facebook.net/D1941 COMMIT https://reviews.facebook.net/rHBASEEIGHTNINEFBBRANCH1294395 > Use builder pattern in StoreFile and HFile > ------------------------------------------ > > Key: HBASE-5442 > URL: https://issues.apache.org/jira/browse/HBASE-5442 > Project: HBase > Issue Type: Improvement > Reporter: Mikhail Bautin > Assignee: Mikhail Bautin > Fix For: 0.94.0 > > Attachments: D1893.1.patch, D1893.2.patch, D1941.1.patch, > D1941.2.patch, D1941.3.patch, D1941.4.patch, D1941.5.patch, > HFile-StoreFile-builder-2012-02-22_22_49_00.patch > > > We have five ways to create an HFile writer, two ways to create a StoreFile > writer, and the sets of parameters keep changing, creating a lot of > confusion, especially when porting patches across branches. The same thing is > happening to HColumnDescriptor. I think we should move to a "builder pattern" > solution, e.g. > {code:java} > HFileWriter w = HFile.getWriterBuilder(conf, <some common args>) > .setParameter1(value1) > .setParameter2(value2) > ... > .build(); > {code} > Each parameter setter being on its own line will make merges/cherry-pick work > properly, we will not have to even mention default parameters again, and we > can eliminate a dozen impossible-to-remember constructors. > This particular JIRA addresses StoreFile and HFile refactoring. For > HColumnDescriptor refactoring see HBASE-5357. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira