> This is by far the most interesting and useful thing a WALObserver can do.
You are right. Allowing to modify the waledit on the fly is powerful to the cp
user who are building application based on hbase cp. In fact, our application
is also powered by the such cp methods.
> Casts by
After this change would coprocessors be able to add edits to the WAL on the
fly? This is by far the most interesting and useful thing a WALObserver can
do. If you plan to take this away, might as well just drop WALObserver in
my opinion.
Casts by definition violate the desired encapsulation. If
> 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
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
Would help if we had some idea how other CPs want to interact with in
flight edits. I presume Phoenix isn't the only one who wants to "meddle".
Read-only for CPs seems like a big feature shift to me.
On Sun, May 27, 2018, 10:53 Chia-Ping Tsai wrote:
> hi folks,
>
> I
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,