[
https://issues.apache.org/jira/browse/HBASE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422609#comment-13422609
]
Lars Hofhansl commented on HBASE-6427:
--------------------------------------
Yet another way of looking at is new coprocessor hook.
That would be a hook that sits before the StoreScanner is created (in
Store.internalFlushCache and Store.compact) and be passed the set of scanners
to use, the store and whether this is a major compaction or not (in the
compaction case). Then this hook could optionally return a scanner, and if
non-null scanner is return that will be used for the flush/compaction.
Now, there already are preFlush and preCompact hooks (interestingly the
preFlush is at the region level, whereas the preCompact is at the store level,
which is not quite right I think, I wonder whether we can change that), so I'm
having a hard time naming these hooks accordingly. "preScannerFlush",
"preScannerCompact" doesn't quite sound right.
[~apurtell] Do you have an opinion?
> Pluggable policy for smallestReadPoint in HRegion
> -------------------------------------------------
>
> Key: HBASE-6427
> URL: https://issues.apache.org/jira/browse/HBASE-6427
> Project: HBase
> Issue Type: New Feature
> Reporter: Lars Hofhansl
> Priority: Minor
>
> 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.
> 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
