[
https://issues.apache.org/jira/browse/HBASE-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559931#comment-14559931
]
stack commented on HBASE-13754:
-------------------------------
I see.
This is what you have in the new Interface.
int stream(OutputStream out, boolean withTags)
# Do we need to flag tags? Can we do away w/ this flag being every place,
especially in hbase 2.0?
# I think you want the inverse of CellOutputStream rather than the reverse. So,
then you want something like
https://hadoop.apache.org/docs/current/api/org/apache/hadoop/io/Writable.html
or http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html or
http://hadoop.apache.org/docs/r1.2.1/api/org/apache/hadoop/io/serializer/Serializer.html
or
https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/MessageLite#writeTo(com.google.protobuf.CodedOutputStream)
and then the builder mergeFrom that is in pb.
# 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?
# Don't you also want the opposite, for a Cell being able to deserialize itself
from a Stream?
> 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)
