hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Su Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13624) A few behavior issue with hbase checkandmutate
Date Mon, 08 Jun 2015 23:42:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578069#comment-14578069
] 

Su Chen commented on HBASE-13624:
---------------------------------

Another smaller issue with null value as input.
If there exist a column with empty value "byte[0]", and we call checkandmutate with value
as null, the checkandmutate thinks this is a match, and applies the mutations.
And from the decription in the API, it looks like check should only return true when the column
does not exist, if null is the value.

> 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)

Mime
View raw message