[
https://issues.apache.org/jira/browse/HBASE-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13624:
--------------------------
Affects Version/s: 2.0.0
1.0.1
1.1.0
> 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: 2.0.0, 0.98.9, 1.0.1, 1.1.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
(v6.3.4#6332)
