For me, since we have already exposed WALKey(which is already an interface which only allow adding attributes) and WALEdit(which we do allow adding customized cells to it) in other coprocessor interface like RegionObserver, it does not make sense to remove these methods in WALObserver just because 'we do not want to expose internal states'.
But considering the usage here, it does not make sense to add any cells in preWALWrite because the cells will only be in WAL but not in memstore, but when replaying, there are no CP hooks that could allow you to filter these cells out... So for me I prefer we could keep these methods in WALObserver but add comments to tell users you'd better not change the WALEdit here unless you know what you are doing. Thanks. 张铎(Duo Zhang) <palomino...@gmail.com> 于2024年8月13日周二 21:19写道： > > This is a cleanup before the 2.0.0 release. > > The umbrella issue is HBASE-18169, the issue for WALObserver is HBASE-19074. > > I think the intention here is to not expose too many internal states > to CP users which may mess things up, like changing the memstore size > without adding any actual data... > > Istvan Toth <st...@cloudera.com.invalid> 于2024年8月13日周二 14:43写道： > > > > As far as Phoenix is concerned, only postWALWrite is used, and only in an > > integration test, which should be easy to change if > > we can still access the required data. > > > > WALAnnotationIT.AnnotatedWALObserver.postWALWrite(ObserverContext<? extends > > WALCoprocessorEnvironment>, RegionInfo, WALKey, WALEdit) > > > > However, I wonder if exposing the internal WAL related types in a method > > that specifically hooks into WAL processing is really a problem. > > > > Istvan. > > > > > > On Mon, Aug 5, 2024 at 5:04 PM Duo Zhang <zhang...@apache.org> wrote: > > > > > These two methods are marked as deprecated and the plan is to remove > > > them in 3.0.0 release. > > > > > > But the javadoc says > > > > > > To be replaced with an alternative that does not expose > > > InterfaceAudience classes such as WALKey and WALEdit. > > > > > > But there are no such methods for now. > > > > > > So I wonder whether there are actual usages of these two methods in > > > the community. If so, I think we need to change the deprecation cycle > > > to remove them in 4.0.0, until we introduce the alternate methods. > > > > > > Thoughts? > > > > > > Thanks. > > > > > > > > > -- > > *István Tóth* | Sr. Staff Software Engineer > > *Email*: st...@cloudera.com > > cloudera.com <https://www.cloudera.com> > > [image: Cloudera] <https://www.cloudera.com/> > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > ------------------------------ > > ------------------------------
