[ https://issues.apache.org/jira/browse/HBASE-18825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175470#comment-16175470 ]
stack commented on HBASE-18825: ------------------------------- Ok. Thanks for the philosophy. That helps. So, we disabuse ourselves of any notion that another might want to put in place their own HRegion implemenation -- whether a subclass or a new implementation altogether -- if only because we've never done the work to ensure it is supported? I'm good w/ that (+1 on cleanup of "hbase.hregion.impl" that [~anoop.hbase] helpfully turned up). +1 too on using implementation internally rather than Interfaces. Going via Interfaces which are NOT IA.Private means we limit our ability to change. I like this observation. We need to put it up on the hbase dev billboard (I can add to dev section in guide at least). We make same call for entities below HRegion so, it is not possible to provide an alternate Store? I'm good with that. What about StoreFile? I'm thinking about alternate HFile implementations. What if someone wants to plug in a columnar-based file format? Or we want to do a V4 of HFile. This is harder for me to swallow. Looking at your patch though, I see that you do not disturb StoreFileReader nor StoreFileWriter. So it seems like alternate HFile implementations are still possible? If so, good. That Region and Store were made to feed CP is also an interesting observation. It seems like Region gets pretty wide usage in the codebase since its introduction, beyond CP-only use. No harm I suppose. So, I buy-in but need clarification around new HFile implementations. I'd also like to help message this philosophy so it sees adoption beyond [~Apache9] contribs. > Use HStoreFile instead of StoreFile in our own code base and remove > unnecessary methods in StoreFile interface > -------------------------------------------------------------------------------------------------------------- > > Key: HBASE-18825 > URL: https://issues.apache.org/jira/browse/HBASE-18825 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors > Reporter: Duo Zhang > Assignee: Duo Zhang > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18825.patch, HBASE-18825-v1.patch, > HBASE-18825-v2.patch, HBASE-18825-v3.patch, HBASE-18825-v3.patch > > > Use generic types to avoid too many casts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)