hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suraj Varma (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-4999) Constraints - Enhance checkAndPut to do atomic arbitrary constraint checks
Date Wed, 14 Mar 2012 08:45:46 GMT

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

Suraj Varma updated HBASE-4999:

    Affects Version/s:     (was: 0.92.0)
        Fix Version/s:     (was: 0.94.0)
> Constraints - Enhance checkAndPut to do atomic arbitrary constraint checks
> --------------------------------------------------------------------------
>                 Key: HBASE-4999
>                 URL: https://issues.apache.org/jira/browse/HBASE-4999
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, coprocessors
>            Reporter: Suraj Varma
>              Labels: CAS, checkAndPut, constraints
> Related work: HBASE-4605
> It would be great if checkAndPut (CAS) can be enhanced to not just use a value comparison
as a gating factor for the put, but rather have the capability of doing arbitrary constraint
checks on the column value (where the current comparinator approach is a subset of possible
constraints that can be checked). Commonly used constraints (like comparisons) can be provided
out of the box and we should have the ability to accept custom constraints set by the client
for the checkAndPut call. 
> One use-case would be the ability to implement something like the below in HBase.
> Pseudo sql: 
> update table-name
> set column-name = new-value
> where (column-value - new-value) > threshold-value
> ... where the mutation would go through only if the specified constraint in the where
clause is true.
> Current options include using a co-processor to do preCheckAndPut/postCheckAndPut constraint
checks - but this is not atomic. i.e. the row lock needs to be released by the co-processor
before the real checkAndPut call, thus not meeting the atomic requirement. 
> Everything above is still meant to be at row level (so, no cross-row constraint checking
is implied here).
> And ideal end result would be that an HBase client would be able to specify a set of
constraints on multiple column qualifiers as part of the checkAndPut call. The call goes through
if all the constraints are satisfied or doesn't if any of the constraints fail. And the above
checkAndPut should be atomically executed (just like current checkAndPut semantics).

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


View raw message