That really makes me groan (we have downstream users depending on code
we've explicitly said "don't use"), but if that's what it is given the
current state, so be it. My complaining won't fix it.
Thanks.
On 9/21/17 4:25 PM, Sean Busbey wrote:
We have lots of examples of including non-Public stuff in Public APIs.
we have docs that advise folks to be wary on relying on them beyond
opaque symbols.
ref: http://hbase.apache.org/book.html#hbase.client.api.surface
On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser <els...@apache.org> wrote:
I was going to suggest LimitedPrivate in my original, but this doesn't make
sense as we're exposing Public API via CellUtil.
It seems odd to me that we wouldn't treat the cell tags as a supported API
call. However, I'm happy to remain "confused" if the rest of folks don't
consider tags to be intended for users :)
On 9/21/17 3:15 PM, Ted Yu wrote:
Can we mark Tag LimitedPrivate ?
We know how ATS uses Tags so it should be straight forward to keep their
usage intact.
On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser <els...@apache.org> wrote:
Hiya,
(Background, I'm starting what is likely to be an onerous task of looking
through downstream components and seeing what is broken with the latest
hbase-2.0.0*)
Looking at YARN's use of HBase for the Application TimelineServer, I see
that they're relying on the Tag interface.
Presently, Tag is marked as Private, yet we expose it via the Public
CellUtil.
My gut reaction is that we should bump Tag up Public since the intent is
for downstream users to, ya know, use those Tags. Any objections?
If we don't want to expose Tag, we should make a pass over the Public
methods and mark them as Private (so not as to provide a Public method
with
Private objects). CellUtil#getTag(Cell, byte) would be one such example.
- Josh
