[
https://issues.apache.org/jira/browse/HBASE-19112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265432#comment-16265432
]
ramkrishna.s.vasudevan commented on HBASE-19112:
------------------------------------------------
Before I prepare a patch few doubts,
Are we first going to add the necessary new APIs to RawCell/ExtendedCell and
deprecate the other APIs in Cell ?
Say for eg : Mark @deprecated for getTagsXXX and getSeqId in Cell and add
corresponding APIs in ExtendedCell/RawCell.
Let all the existing core code to still point to the
cell.getTagXXX/cell.getSeqId only. Later in master lets clean all when we
actually allow core to have RawCell/ExtendedCell flowing through?
Some reasons are like say if RawCell currently uses the PrivateCellUtil.getTags
to retrieve the tags rather than each cell having an impl. Now if I need to
really add the impl I need to make sure that the incoming cell is RawCell so
that what ever impl is added we can make use of it directly in the code instead
of typecasting. Currently we need to do ((RawCell)cell) every where.
I found that getTagsLength is getting used through out the code than
getTagsArray and getTagsOffset. So if getTagsLength moves to RawCell i need the
typecast.
Similary getSequnceId has got lot of references too. So what can be the
strategy for branch-2 and master now? Thoughts!!!
> Suspect methods on Cell to be deprecated
> ----------------------------------------
>
> Key: HBASE-19112
> URL: https://issues.apache.org/jira/browse/HBASE-19112
> Project: HBase
> Issue Type: Bug
> Components: Client
> Reporter: Josh Elser
> Assignee: ramkrishna.s.vasudevan
> Priority: Blocker
> Fix For: 2.0.0-beta-1
>
>
> [~chia7712] suggested on the [mailing
> list|https://lists.apache.org/thread.html/e6de9af26d9b888a358ba48bf74655ccd893573087c032c0fcf01585@%3Cdev.hbase.apache.org%3E]
> that we have some methods on Cell which should be deprecated for removal:
> * {{#getType()}}
> * {{#getTimestamp()}}
> * {{#getTag()}}
> * {{#getSequenceId()}}
> Let's make a pass over these (and maybe the rest) to make sure that there
> aren't others which are either implementation details or methods returning
> now-private-marked classes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
