[
https://issues.apache.org/jira/browse/HBASE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772413#comment-13772413
]
Dan Burkert commented on HBASE-9576:
------------------------------------
Recently I have been looking a lot at the RPCs as I'm trying to implement an
HBase client. I have some opinions on changes/cleanups that should happen.
I'm coming at this as someone who, for the most part, doesn't know how far
reaching these changes these would be, and in particular have not considered
backwards-compatibility issues. Nonetheless, here is a list of some of the
more attainable cleanups I would like to see:
1) MultiRowMutationProcessorMessages.protos defines two messages, neither of
which is ever used
2) Consider combining MasterAdmin.proto and MasterMonitor.proto. The
distinction between the two is unclear, and there is a lot of overlap. Which
brings us to,
3) IsMasterRunning RPC is repeated in Master.proto, MasterAdmin.proto, and
MasterMonitor.proto. Consider removing Master.proto.
4) The confusion and overlap between the RowProcessor endpoint and
MultiRowMutation exists even at the proto level. This is definitely an issue
throughout more (all) of the codebase, but nonetheless there are two different
RPCs to accomplish the same task: atomically update intra-region cells. My
opinion is that these two things need to be combined all the way through the
codebase, in the client, the protos, and the server. In the case of protos, it
should just be an addition RPC in Client.proto
5) Consider renaming Admin.proto to RegionServerAdmin.proto, and Client.proto
to RegionClient.proto. This would be more inline with MasterAdmin.proto and
RegionServerStatus.proto.
6) I understand that message components being required/optional is usually
driven by the peculiarities of ProtoBuffers and planning for backwards
compatibility, but the .proto files should indicate which of the components in
the messages are in actuality optional in the comments. For instance,
RPC.proto/RequestHeader.method_name is labeled as optional, but I think in the
code now it is always included. It is a barrier to creating a client if it is
unclear which parts of messages are in actuality optional.
> Fixups in hbase protobuf
> ------------------------
>
> Key: HBASE-9576
> URL: https://issues.apache.org/jira/browse/HBASE-9576
> Project: HBase
> Issue Type: Task
> Components: Protobufs
> Reporter: stack
>
> Benoit was looking at out pbs. Had following remarks:
> {code}
> ...there is something that doesn't make sense to me...a MutateRequest can
> have a Condition...the Condition has row/family/qualifier...so for a single
> KV CAS, one needs to specify the...row/family/qualifier twice...once in the
> MutationProto and once in the Condition...not a huge deal...just weird
> ...also in Comparator.proto, both BinaryComparator and BinaryPrefixComparator
> (and BitComparator too actually) would have been better off without
> ByteArrayComparable, which seems a useless pb, but no big deal either
> {code}
> Will keep this issue open as place to accumulate pb fixups.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
