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 <[email protected]> 于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 >
