Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Incomplete
-
0.98.9, 1.0.1, 1.1.0, 2.0.0
-
None
-
None
-
None
-
Important
Description
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.