[
https://issues.apache.org/jira/browse/HBASE-19134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19134:
--------------------------
Attachment: HBASE-19134.master.004.patch
> 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,
> HBASE-19134.master.004.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)
