[
https://issues.apache.org/jira/browse/HBASE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859845#comment-13859845
]
James Taylor commented on HBASE-10256:
--------------------------------------
One other change that would be useful. Instead of returning a boolean return a
Long with null meaning that check failed and otherwise the Long represents the
timestamp of the Delete (or Put). This conveys more information, as Phoenix
caches based on the timestamp of the mutation. If we can get the actual
timestamp (in the case where HConstants.LATEST_TIMESTAMP was used in the
Delete/Put), then knowing the server timestamp is useful information. Without
this, an extra round trip ends up being required later.
FWIW, I've been able to work around all these issues with region observers
which is really nice. It's just more work than it needs to be, though. Plus I'm
not sure perf-wise if my Get/Put in the region observer will perform as well as
the other methods (I suspect it's probably equivalent, though).
Happy New Years!
> Handling of value argument being null for checkAndDelete
> --------------------------------------------------------
>
> Key: HBASE-10256
> URL: https://issues.apache.org/jira/browse/HBASE-10256
> Project: HBase
> Issue Type: Improvement
> Reporter: James Taylor
>
> IMO, it would be more useful if when a null is supplied as the value for
> checkAndDelete, that it add the Delete marker if the row exists rather than
> if it doesn't exist (i.e. the opposite of checkAndPut). I think the most
> common use case for checkAndDelete is to delete a row if it exists and tell
> me that you deleted it. With the current implementation, it adds a Delete
> marker only if the row does not exist when you supply a null value which IMO
> is not very useful.
> My workaround is to add another "known" KeyValue to my row with a fixed value
> and then call checkAndDelete passing in this known value. Also, FWIW, if an
> empty byte array is passed through (a valid value), it treats it the same as
> if null was passed through, which is another separate bug.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
