[
https://issues.apache.org/jira/browse/HBASE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889304#action_12889304
]
HBase Review Board commented on HBASE-2553:
-------------------------------------------
Message from: [email protected]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/325/#review412
-----------------------------------------------------------
Ship it!
+1
There are a few minors in the below perhaps worth considering.
src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
<http://review.hbase.org/r/325/#comment1756>
Why not just use newKv? If there is a kv in front of newKv, then our
counters are going to be off?
src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
<http://review.hbase.org/r/325/#comment1759>
See KeyValue.matchingQualifier() or KeyValue.matchingColumn
src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
<http://review.hbase.org/r/325/#comment1760>
There is a tab here?
- stack
> Revisit IncrementColumnValue implementation in 0.22
> ---------------------------------------------------
>
> Key: HBASE-2553
> URL: https://issues.apache.org/jira/browse/HBASE-2553
> Project: HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.92.0
>
>
> right now we are using too much of the old get code, we need to review that
> and constrain how this works but without breaking ICV.
> Also we should be resetting the timestamp on every ICV call, and removing the
> older version. Instead of 'updating' an ICV "in place" we should be adding a
> new one, removing the old one from memstore (if it is there). This will play
> well with the atomic approach added in HBASE-2248 since we are only touching
> 1 KeyValue at a time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
