Hi! Now that HBase 3 is (this time really) right around the corner we need to consider how to support it in Phoenix.
I've already made a POC patch in 2024, and most of the non-breaking changes (Mostly Hbase 1.x API cleanups) have already been applied to HBase. Old OMID thread: https://lists.apache.org/thread/dqs5qr32cl4bsy7ypsp9o0pfl2lv7r0r Old HBase thread (with Viraj's answer): https://lists.apache.org/thread/xzb9143gtth2rl79p7871b12j82ko15q However, since that POC patch there were more breaking-ish API changes in HBase. The following changes in particular require ugly workarounds if we want to keep HBase 2 and 3 support in the same branch: - HBASE-23797 Let CPEPs also use our shaded protobuf - HBASE-28587 Remove deprecated methods in Cell - HBASE-28644 Use ExtendedCell instead of Cell in KeyValueScanner - HBASE-28862 Change the generic type for ObserverContext from 'RegionCoprocessorEnvironment' to '? extends RegionCoprocessorEnvironment' in RegionObserver The protobuf changes require code rewrite, we can solve this with the rewrite maven plugin and the build-helper plugin. (This change was already present in the old WIP patch) In many cases we need to cast Cells to ExtendedCells to access sequence or the tags. This is not as horrible as it sounds, as the Cell objects we work on these cases are already ExtendedCells anyway (at least according to my testing so far) (This is new) Scanner and coprocessor interface methods have changed their generics types. The only way I could resolve this was removing by the generics in the implementation classes, and explictly casting where needed. (This is also new) My current WIP (but mostly working) patches are here: https://github.com/apache/phoenix-omid/pull/152 https://github.com/apache/phoenix/pull/2300 Both patches are unpolished, but I could not find a way to remove the really ugly warts (the protobuff stuff and the generics removal), so unless someone finds better solutions, they won't be significantly less ugly. Based on my current knowledge, we have two options (IMO ignoring HBase 3 would be equivalent to letting Phoenix slide into irrelevance, so I do not think it is an option) - Go with my current changes (plus any improvements found) - Open a new branch for HBase 3.0 Of course neither is optimal, we can only choose between two evils: - The ugly hacks required to support HBase 2/3 in a single branch - Or maintaining an extra branch My preference is the single branch option, as that one is easier to maintain in the future, and the pain caused by the uglyness is less than the pain of maintaining two active development branches. Please share your thoughts: - Do you agree that we should support HBase 3.0 ASAP after its release ? - Do you have suggestions for less ugly ways to support Hbase 2/3 in a single branch ? - Do you prefer the single or multi-branch solution ? - And of course anything else on the topic Best regards Istvan
