[
https://issues.apache.org/jira/browse/HBASE-13624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529721#comment-14529721
]
Srikanth Srungarapu commented on HBASE-13624:
---------------------------------------------
bq. The results with comparators are reversed.
If you look at the internals of checkAndXXX implementations, all use the same
logic. I don't think this is specific to checkAndMutate.
bq. "NOT_EQUAL with input value null" should be interpreted as "if column
exists, apply mutations", instead of "if column is missing, apply mutations"
>From the javadoc, "If the passed value is null, the check is for the lack of
>column (ie: non-existence)". So, right now it doesn't care about comparator
>once the value is null. I believe the same is the case about other
>checkAndXXXX implementations.
bq. The mutations can be on a row which is different from the one in the check.
The main intent behind introducing checkAndXXX methods is, you perform the
check on the row and if it passes, then you operate on the *same* row
accordingly. From implementation pov, what happens is you obtain row lock ,
peform the check, operate if needed and close the row lock. IMHO, the api is
getting abused, if you try to perform checks on one row and operate on another
row.
> 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)
