[ https://issues.apache.org/jira/browse/HBASE-19134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283177#comment-16283177 ]
stack commented on HBASE-19134: ------------------------------- .003 Fix tests (dumb attempt at reusing empty WALKeys went awry). > Make WALKey an Interface; expose Read-Only version to CPs > --------------------------------------------------------- > > Key: HBASE-19134 > URL: https://issues.apache.org/jira/browse/HBASE-19134 > Project: HBase > Issue Type: Bug > Components: Coprocessors, wal > Reporter: stack > Assignee: stack > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19134.master.001.patch, > HBASE-19134.master.002.patch, HBASE-19134.master.003.patch > > > WALKey has been made IA.Private in hbase2. Even so, given we don't have an > alternative to expose at this time, it is exposed to coprocessors still at a > few (now deprecated) locations. > In review of HBASE-18770, [~chia7712] makes reasonable suggestion that what > we expose to CPs be a read-only WALKey. He gets pushback on doing this for > hbase2 (Do we even want to expose WALKey to CPs, is WALKey right going > forward, etc.). Chia-Ping comes back w/ the below (copied from HBASE-18770): > What we want to fix for WALKey are shown below. > * expose some methods to CP user safety > * refactor/redo > As I see it, adding an interface exposed to CP user for WALKey is a right > choice because it can bring some benefit. > * We can expose part of WALKey's methods to CP users - a read-only interface > or an interface with some modifiable setting. > * The related CP hooks won't be deprecated > * Doing the refactor for WALKey doesn't essentially impact the CP hook after > 2.0 release. > Although, it will be better to redo WALKey before 2.0 release. In short, I > think it warrants such an interface. > (We both agree this would be a load of work given WALKey is written to > HFiles. Warrants a look though). -- This message was sent by Atlassian JIRA (v6.4.14#64029)