[GitHub] [hbase] gjacoby126 commented on pull request #2707: [HBASE-25328] Make some Tag related classes annotation as LimitatePrivate.

[GitBox]

gjacoby126 commented on pull request #2707:
URL: https://github.com/apache/hbase/pull/2707#issuecomment-734076588


   Question: would it be possible to do the following? 
   
   1. Mark sufficient existing APIs to create/read from Tags in coproc as 
LimitedPrivate(COPROC) to unblock existing Phoenix development efforts _but 
only for branch-2_ and if needed branch-1
   2. Develop a better, more abstracted LimitedPrivate API as @anoopsjohn , 
@Apache9 and @shahrs87 are discussing above, to be released in HBase 2.5 (and 
potentially 1.7)
   3. When HBase 3.0 is released, the new LimitedPrivate API in 2.5 becomes the 
only Tag API for coprocs. Reverting the temporary LimitedPrivate annotations on 
the existing methods to Private would be less impactful as part of a major 
release transition. 
   
   This gives Phoenix and other coproc developers an approved path that works 
for all current release branches without a long delay. It avoids either 
ignoring the IA, or having an awkward situation where "Phoenix 5.1 with HBase 
2.5 supports Feature X, but the same Phoenix with HBase 2.4 doesn't", which 
already happens too often for other reasons. 
   
   But we still further the HBase community's long-standing efforts to better 
abstract away implementation details and only expose interfaces. 
   
   @anoopsjohn @Apache9 and @apurtell , wdyt? Of course happy to hear other 
suggestions. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [hbase] gjacoby126 commented on pull request #2707: [HBASE-25328] Make some Tag related classes annotation as LimitatePrivate.

[GitBox]

gjacoby126 commented on pull request #2707:
URL: https://github.com/apache/hbase/pull/2707#issuecomment-733846240


   Quick recap for those who haven't been following this issue:
   1. @shahrs87 wanted to add the ability to add a custom Tag to a Delete 
marker, and was told that client reads or writes to Tags of any sort weren't 
allowed as features, but that a coproc could be used as an acceptable 
workaround.
   2. It turned out that a coproc could be written, but only with code using 
calls that were deprecated and/or IA.Private. On the  Phoenix review, I asked 
@shahrs87 to fix this. 
   3. @shahrs87 raised this PR
   
   And some more points:
   
   - Yesterday I noticed that a different Phoenix feature which I did not 
implement or review was recently committed using IA.Private and deprecated APIs 
to do something similar with Tags in a coproc. Clearly there's a general need 
here. 
   -  Phoenix supports HBase 1.3+ on branch-1 and 2.1+ on branch-2, with 1.3 
and 2.1 support to be dropped after our next release, likely in the next month 
or two. 
   - Because of semantic versioning, @anoopsjohn 's suggestion of a new LP API 
would only be usable in HBase 2.5+, which probably won't release until 
mid-2021, and likely wouldn't be released in a Phoenix version until late 2021. 
Using the "bad" APIs gets @shahrs87 's Phoenix feature released in the next 
month or so, and usable in Phoenix for all HBase versions, not just 2.5 and 
maybe 1.7. 
   
   I agree that @anoopsjohn and @Apache9 's proposals would be the right 
solution a few years back when 2.0 was being developed, but they're really 
expensive to do _now_.  I'm wearing three hats on this issue as an HBase 
contributor, Phoenix committer, and at my day job as an eventual user of the 
feature @shahrs87 is developing. 
   
   I'd like to do the right thing by all 3 of my hats -- is there a right thing 
that _doesn't_ involve @shahrs87 and I waiting a year to do something in a 
coproc the HBase community long ago decided was OK to do?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org