[
https://issues.apache.org/jira/browse/HBASE-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560338#comment-14560338
]
Anoop Sam John commented on HBASE-13754:
----------------------------------------
Yes it is like the PB writeTo(CodedOutputStream)
bq.You could just add it to the Cell Interface? Would that be obnoxious? It is
not too much to expect that every Cell be able to serialize itself on to a
Stream like the pb writeTo for Message?
I agree. It is ok to expect every cell to have an impl for writing itself to an
OS. But we need to consider for BC issues? Users might have their own impl of
Cells? If we add new API is that ok? If that level is fine I am ok to add. I
selected this path to be on safe side
bq.Don't you also want the opposite, for a Cell being able to deserialize
itself from a Stream?
I think that is the correct path especially if we add the method to Cell
interface itself. All the Cell impls to have default constructor. The Codec
will create a Cell object of its choice and ask the object to make its data
from the stream. But with the new interface type I thought to just leave it
as we are not sure whether all Cells will impl the new interface.
bq.Do we need to flag tags? Can we do away w/ this flag being every place,
especially in hbase 2.0?
I fear we can not. We have Codecs for with and with out Tags. But when it comes
to serialize on wire, the decision to include or exclude Tags is based on the
user/scenario. That is also one more reason to keep the API Away from public
Cell. The new interface can be Private audience and we are free to change it
when we have a better solution for avoiding sensitive tags to be sent back to
client. Ideally we would like to use Cell Tags at client level itself. Users
are free to add Tags of their own. Also the system adds certain Tags at
server. The system added Tags should not get send to client. But others has
to.. When we can do this, all these withTags can get removed.
Considering these I still feel it is safe to NOT add new method to Cell
interface but have it to a new Interface (which extends Cell) . The impls that
we have, ie. KeyValue, NoTagsKeyValue, ClonedSeekerState (We need a better
name) etc can impl the new interface. wdyt?
> Allow non KeyValue Cell types also to oswrite
> ---------------------------------------------
>
> Key: HBASE-13754
> URL: https://issues.apache.org/jira/browse/HBASE-13754
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-13754.patch
>
>
> While making the cellblock for returning data to client, we have to write the
> cell data into an OutputStream. KeyValue has a static oswrite() method with
> which it can write data in one go. (KeyValue components are in a single
> byte[]). For other cell implementation, we will call getXXXLength() and
> getXXXArray() and write each component one after the other. This is not
> efficient as the KeyValue way. In fact other cell impls also may have one
> contigous byte[] backing for keys atleast. (See ClonedSeekerState) We can
> optimize for such Cells also.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
