[jira] [Resolved] (HBASE-13624) A few behavior issue with hbase checkandmutate

["Andrew Kyle Purtell (Jira)" <ji...@apache.org>]

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

Andrew Kyle Purtell resolved HBASE-13624.
-----------------------------------------
    Resolution: Incomplete

> A few behavior issue with hbase checkandmutate
> ----------------------------------------------
>
>                 Key: HBASE-13624
>                 URL: https://issues.apache.org/jira/browse/HBASE-13624
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.9, 1.0.1, 1.1.0, 2.0.0
>            Reporter: Su Chen
>            Priority: Critical
>
> There are several problems with checkandmutate behavior.
> 1.  The results with comparators are reversed. 
>      For example, in a table we have a row like below      
>      key=surow3 column=fam0:col0 timestamp=1430849691461 type=Put vlen=12 value=surow3-val00
>      If we run checkandmutate on it with operator CompareOp.GREATER and input value "surow2", checkandmuate does not apply the mutations, however, if we change the operator to CompareOp.LESS , it applies the mutation.
>      Since the api has signature like 
>      checkAndMutate(row, family, qualifier, CompareOp, input_value, mutation)
>      it should behave as "if (value_in_table_of_given_row_family_qualifier > input_value), then apply mutations", however, in current implementation, the left-hand and right-hand side of the operator are reversed.
> 2.  "NOT_EQUAL with input value null" should be interpreted as "if column exists, apply mutations", instead of "if column is missing, apply mutations"
>      In current implementation, as long as the input value is null, then checkandmutate applies the mutations if the column is missing, no matter what compareop is.
>      However, for  
>      checkAndMutate(row, family, qualifier, CompareOp.NOT_EQUAL, null, mutation)
>      it should be interpreted as "if that row:family:qualifier exists, apply the mutations".
> 3. The mutations can be on a row which is different from the one in the check.
>    For example, we have a table with the following two rows
>    key=r0 column=f0:c0 timestamp=1430860202859 type=Put vlen=6 value=r0-v00
>    key=r1 column=f0:c0 timestamp=1430860202879 type=Put vlen=6 value=r1-v00
>    If we run checkandmute with
>    RowMutations rm1 = new RowMutations(row1);
>    rm1.add(...);
>    checkAndMutate(Bytes.toByte("r0"), Bytes.toByte("f0"), Bytes.toByte("c0"), CompareOp.EQUAL, Bytes.toByte(r0-v00), rm1)
>    The checkandmutate will apply the mutations on r1, which is NOT correct. checkandput/delete do not have this issue.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)