[
https://issues.apache.org/jira/browse/HBASE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852090#action_12852090
]
Andrew Purtell commented on HBASE-2395:
---------------------------------------
bq. But is there a plan for how to do it in a second pass?
Handwaving: THBase, or similar.
bq. I don't see the point of intra-region constraints if they don't work
cross-region too.. is there a use case for such a thing?
Well one thing you could do is tie versions of values in one column family to
versions of values in another. If a version is deleted (garbage collected) or
expires (ttl), propagate. Or hold on to versions in one if there are references
in another, even if that means too many versions. Even in the same row this
could be useful. Pushes some of the challenge of maintaining app level
consistency from the client up to the regionserver, which has a global view.
> Coprocessors: implement propagation constraints
> -----------------------------------------------
>
> Key: HBASE-2395
> URL: https://issues.apache.org/jira/browse/HBASE-2395
> Project: Hadoop HBase
> Issue Type: Sub-task
> 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.
-
You can reply to this email to add a comment to the issue online.
