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)
