[
https://issues.apache.org/jira/browse/HBASE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-2395:
----------------------------------
Issue Type: New Feature (was: Sub-task)
Parent: (was: HBASE-2000)
> Coprocessors: implement propagation constraints
> -----------------------------------------------
>
> Key: HBASE-2395
> URL: https://issues.apache.org/jira/browse/HBASE-2395
> Project: HBase
> Issue Type: New Feature
> Components: coprocessors
> Reporter: Andrew Purtell
> Priority: Minor
>
> Some fevered stuff I posted to hbase-dev@:
> A coprocessor or coprocessors (which implement RegionObserver) could
> implement propagation constraints in a pluggable manner, is one possibility.
> Coprocessors also get an ioctl-like interface which could be the channel for
> attaching constraints to KVs.
> {quote}
> First, what about attaching metadata (itself KVs) to KVs in the store, in a
> way that it is efficient to look up the metadata for a given KV or set of KVs?
> Second, what about the notion of references? For the case above specifically,
> metadata on an "inode" KV that consists of a list of pointers to other KVs.
> When deleting the "inode" KV -- one that fell off the tail of a stack of
> versions -- at compaction time, then the store could follow the pointers and
> delete the referenced values also. Or better, decrement a specified Long
> encoded KV and then take the delete action on another specified KV (or set of
> KVs) if the result <= 0.
> So just to be clear I'm not advocating building my use case into HBase -- it
> is a motivating example -- but rather there is perhaps some interesting
> generic primitives to consider here. They could support mechanisms for
> referential integrity that people coming from RDBMS are quite familiar with.
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
