[ https://issues.apache.org/jira/browse/HBASE-21640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729571#comment-16729571 ]
Hudson commented on HBASE-21640: -------------------------------- Results for branch master [build #683 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/683/]: (x) *{color:red}-1 overall{color}* ---- details (if available): (/) {color:green}+1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/master/683//General_Nightly_Build_Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/master/683//JDK8_Nightly_Build_Report_(Hadoop2)/] (x) {color:red}-1 jdk8 hadoop3 checks{color} -- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/master/683//JDK8_Nightly_Build_Report_(Hadoop3)/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > Remove the TODO when increment zero > ----------------------------------- > > Key: HBASE-21640 > URL: https://issues.apache.org/jira/browse/HBASE-21640 > Project: HBase > Issue Type: Improvement > Reporter: Guanghao Zhang > Assignee: Guanghao Zhang > Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.2, 2.0.4 > > Attachments: HBASE-21640.master.001.patch, > HBASE-21640.master.002.patch, HBASE-21640.master.003.patch > > > > {code:java} > // If delta amount to apply is 0, don't write WAL or MemStore. > long deltaAmount = getLongValue(delta); > // TODO: Does zero value mean reset Cell? For example, the ttl. > apply = deltaAmount != 0; > {code} > This is an optimization when increment 0. But it introduced some new problems. > 1.As the TODO said, Does zero value mean reset ttl? > 2.HBASE-17318 have to introduce a new variable "firstWrite" because it don't > apply 0. > 3. There is a coprocessor method postMutationBeforeWAL to return a new cell. > But it may be not applied. > > {code:java} > // Give coprocessors a chance to update the new cell > if (coprocessorHost != null) { > newCell = > coprocessorHost.postMutationBeforeWAL(mutationType, mutation, > currentValue, newCell); > } > // If apply, we need to update memstore/WAL with new value; add it toApply. > if (apply || firstWrite) { > toApply.add(newCell); > } > {code} > > So my proposal is remove this optimization. Any suggestions are welcomed. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)