[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Make WALEdit an Interface; expose Read-Only version to CPs

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 it will be
necessary to always cast to accomplish a thing, and that thing is something
we intend to support, then this would suggest an interface design problem.

On Sun, May 27, 2018 at 8:53 AM, Chia-Ping Tsai <chia7712@xxxxxxxxxx> 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

Best regards,

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk