There are a bunch of issues raised here, some micro and some macro. I'll tackle them in two separate messages so they're short(ish) enough for people to bother reading. :-) For this one I wear my "HBase contributor" hat.
First the micro, which is my patch on HBASE-22623 which sparked a lot of passionate disagreement. I want to start by saying that I really appreciate the work that Duo and many others have done to improve the abstraction and cleanliness of the code base -- implementing a change to the write path in both branch-1 and master, you really feel the improvement in the later code. In a few places though, that cleanup left contradictions. One of them is WALEdit, which is LimitedPrivate for coprocessors and replication, and is already exposed in about 10 non-deprecated cooprocessor hooks between at least two interfaces. But the comments say it should never be exposed to coprocs, (I _think_ it means "never before WAL append", but that's not what it says) and the add methods are marked IA.Private. I think the fundamental mistake here is to have comments which contradict the IA annotation, and to enforce the comments over the IA contract. If a class is LimitedPrivate for coprocs and replication, then it's part of the public API for those components, and should be safe to consume. If the community later decides it's not safe, the IA can be changed and _all_ coproc + replication methods using WALEdit can be deprecated in favor of some new safer interface. As I believe was once done for HLogKey vs WALKey. But that hasn't (yet anyway) been done for WALEdit, and patches which honor the IA contract, as I tried to do, shouldn't be rejected because they violate a private understanding. I'm (non-bindingly) strongly against any proposal to create an API which is deprecated on the moment of its birth, as has been proposed above. That seems nonsensical to me, since a deprecation means "don't use this", so what's the point? Slipping my Phoenix hat on, I don't want Phoenix to be a trespasser tolerated on sufferance, but based on good, clear abstractions and APIs negotiated between the two communities, with those APIs open to other projects as well. But more on that in the next one, which I'll write in the (Pacific time) morning. Geoffrey On Thu, Aug 8, 2019 at 6:39 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > When releasing 2.0.0 we faced a lot of problems because we exposes so many > internal classes to CPs. It is really hard to both consider the > compatibility and development on HBase. And then we have done lots of works > to abstract interfaces for CPs to use and hide the actual implementation > classes to be HBase only. > > The work is not fully done, so we still left some methods which exposes > internal classes there with a deprecated annotation, I think most of them > are for Phoenix. This is a trade off and I think it is also acceptable. > Phoenix could still use the deprecated methods, and we will not remove them > unless we find an alternate solution. And I think if anyone wants to remove > them without replacment you will first jump out and give a -1 :) > > Specific to HBASE-22623, I still think we should add the deprecated > annotation to keep the API consistent, otherwise users will be confused > that whether they can use the WALEdit. And on the abstraction of WALEdit, I > think we used to rely on a high level abstraction in HBASE-20952. But now > since there is little progress there, I think we can start the work of > abstracting WALEdit only. > > Thanks. > > Andrew Purtell <apurt...@apache.org> 于2019年8月9日周五 上午3:21写道： > > > Please let me direct your attention to the tail of HBASE-22623 for a > larger > > discussion. I tried to sum it up as follows: > > > > An opinion that we should have more and more coprocessor interfaces to > > address new use cases is valid. An opinion that coprocessors are too > > invasive and should be 'cleaned up' is also valid. An opinion that the > > compatibility headaches of coprocessor interfaces are annoying is valid. > An > > opinion that Phoenix can be considered as a valid use case when > considering > > interface changes is valid. An opinion that only HBase level concerns > > should motivate API changes is valid. These opinions are strawmen. I > think > > they approach actual positions in the community but I do not imply any > > specific person has one of them. These strawmen are at least partially > > contradictory. It is going to be an ongoing process to sort them out into > > something that makes sense and can get consensus. > > > > So while as committer I am moving forward on HBASE-22623 because I don't > > see a veto but instead a disagreement on the margins (deprecation or not) > > motivated on larger principles, I also want to raise the visibility of > the > > disagreement because I think it impacts our relationship with another > > project at Apache at a minimum, but also future technical directions of > an > > important subset of interfaces. > > > > For your consideration. > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
