> What version you thinking @chia-ping? If 2.1/3.0, I feel it is impossible to go in 2.1 since refactoring the WALEdit must break the coprocessors. Given that 2.0 has been released, the 3.0 is more appropriate.
> should we instead be working toward HBASE-16473 *Merge WALEdit and WALKey*? > Or you have a shorter horizon sir? I don't think I have a good answer at this point. I noticed this issue when migrating our CP application from 1.x to 2.0. Since the target version is 3.0, we can take more time to find out a good solution... -- Chia-Ping On 2018/05/29 19:26:21, Stack <[email protected]> wrote: > What version you thinking @chia-ping? If 2.1/3.0, should we instead be > working toward HBASE-16473 *Merge WALEdit and WALKey*? Our WALEdit/WALKey > duplicate info and seem way fatter than they need to be. Would be nice to > revisit these data structures... in light of our experience writing and > replicating. > > Or you have a shorter horizon sir? > > S > > > On Sun, May 27, 2018 at 8:53 AM, Chia-Ping Tsai <[email protected]> wrote: > > > hi folks, > > > > I noticed that we make only the WALKey an interface and we leave the TODO > > in WALEdit. > > > > {code} > > // TODO: Do not expose this class to Coprocessors. It has set methods. A > > CP might meddle. > > @InterfaceAudience.LimitedPrivate({ HBaseInterfaceAudience.REPLICATION, > > HBaseInterfaceAudience.COPROC }) > > public class WALEdit implements HeapSize { > > {code} > > > > WALEdit is used in WALObserver and RegionObserver. It is easy to make the > > WALEdit an read-only interface but Phoenix need to add something to WALEdit > > in order to come in the consistence guarantee. So how we iron this issue > > out? Could we make the WALEdit a read-only interface and encourage phoenix > > in casting the WALEdit to the writable WALEdit? > > > > -- > > chia-ping > > >
