[jira] [Updated] (HBASE-9576) Fixups in hbase protobuf

["Dan Burkert (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-9576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Burkert updated HBASE-9576:
-------------------------------

    Attachment: 0001-HBASE-9576-task1.patch

Here's my followup on my issues, sorry this is so late:

Most of these tasks ended up being more complicated than I expected, but I have attached a patch for #1.

1) The messages in MultiRowMutationProcessorMessages are in fact used (as empty messages), so I rolled them into MultiRowMutationProtos
2) Merging MasterAdmin and MasterMonitor will require many changes to HConnectionManager; definitely big enough to have its own JIRA.  Not sure it's worth the effort, though.
3) Accordingly, IsMasterRunning can't be de-duped because it depends on #2.
5) This will have pretty big repercussions throughout the codebase as well.  To do it right, some methods in the HConnection interface would need to be renamed (i.e. getAdmin, which is package private), and that may be a breaker.  Again, maybe not worth the effort.
6)  My thoughts on this is that the .proto files should be further documented in order to indicate what actually constitutes a valid message, for each type.  At this point, I'm not up to the challenge.  
                
> 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
>         Attachments: 0001-HBASE-9576-task1.patch
>
>
> 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