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

["Su Chen (JIRA)" <ji...@apache.org>]

Su Chen created HBASE-13624:
-------------------------------

             Summary: 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
            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
(v6.3.4#6332)