hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
Date Tue, 04 Oct 2016 05:10:20 GMT
stack created HBASE-16757:
-----------------------------

             Summary: Integrate functionality currently done up as Coprocessor Endpoints into
core.
                 Key: HBASE-16757
                 URL: https://issues.apache.org/jira/browse/HBASE-16757
             Project: HBase
          Issue Type: Task
          Components: Coprocessors
            Reporter: stack


As part of the work over in HBASE-15638, "Shade Protobufs", I could not but help noticing
that of the seven or eight Coprocessor Endpoints bundled with hbase, half should have been
converted to be core long time again. In fact, some of these core CPEPs are no longer viable
as CPEPs, if they ever were, given how intertwined with core they are.

For example, MultiRowMutation, the nice CPEP that allows us do cross-row transactions used
natively amending hbase:meta, has much of its facility baked into core without which it could
not run. In an exercise, I was able to convert this one over without having to alter public
APIs in Table or Admin.

Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it is cast as one
invoked natively by RPC.

VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually depend on VisibiltyLabel
related classes.

SecureBulkLoad is not in any violation being a CPEP provided to add API ahead-of-time since
properly deprecated and already integrated to core but I mention it here for completeness
sake.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message