[
https://issues.apache.org/jira/browse/HBASE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425124#comment-13425124
]
Andrew Purtell commented on HBASE-6427:
---------------------------------------
bq. This means there still might be scenarios where coprocessors for the same
table have the same priority.
Fine, that text needs update. The tie is not broken arbitrarily, it is by load
order.
But you are missing the larger point that both Lars and I have mentioned above,
CPs are not (currently, nor likely) going to be random user modules loaded
blindly with respect to each other. They are deeply embedded in HBase
implementation. If as a system integrator you are deploying coprocessors, you
will be engineering their load/initialization order as well as all other
cluster details. Again, this is an X-Y discussion. It would be best to stick to
the issues in scope to this JIRA. If there are larger design issues you'd like
to consider, let's open a JIRA for those.
> Pluggable compaction policies via coprocessors
> ----------------------------------------------
>
> Key: HBASE-6427
> URL: https://issues.apache.org/jira/browse/HBASE-6427
> Project: HBase
> Issue Type: New Feature
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Minor
> Attachments: 6427-notReady.txt, 6427-v1.txt, 6427-v10.txt,
> 6427-v2.txt, 6427-v3.txt, 6427-v4.txt, 6427-v5.txt, 6427-v7.txt
>
>
> When implementing higher level stores on top of HBase it is necessary to
> allow dynamic control over how long KVs must be kept around.
> Semi-static config options for ColumnFamilies (# of version or TTL) is not
> sufficient.
> This can be done with a few additional coprocessor hooks, or by makeing
> Store.ScanInfo pluggable.
> Was:
> The simplest way to achieve this is to have a pluggable class to determine
> the smallestReadpoint for Region. That way outside code can control what KVs
> to retain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
