You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (Resolved) (JIRA)" <ji...@apache.org> on 2011/10/19 00:43:10 UTC

[jira] [Resolved] (HBASE-2395) Coprocessors: implement propagation constraints

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

Andrew Purtell resolved HBASE-2395.
-----------------------------------

    Resolution: Duplicate

Dup of HBASE-4605
                
> 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.
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