[
https://issues.apache.org/jira/browse/CASSANDRA-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-5751.
-----------------------------------------
Resolution: Won't Fix
Quoting http://wiki.apache.org/cassandra/Counters (parts about the technical
limitation):
{noformat}
Counter removal is intrinsically limited. For instance, if you issue very
quickly the sequence "increment, remove, increment" it is possible for the
removal to be lost (if for some reason the remove happens to be the last
received messages). Hence, removal of counters is provided for definitive
removal only, that is when the deleted counter is not increment afterwards.
This holds for row deletion too: if you delete a row of counters, incrementing
any counter in that row (that existed before the deletion) will result in an
undetermined behavior. Note that if you need to reset a counter, one option
(that is unfortunately not concurrent safe) could be to read its value and add
-value.
{noformat}
So, we know re-incrementing after a deletion doesn't work as it should, but we
don't know how to fix it with the current counter design.
> Columns defined as datatype counter will become 'null' after deletion
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-5751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5751
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.4, 1.2.6
> Reporter: Yangyi Chen
> Priority: Minor
>
> The following statements should reproduce the problem:
> CREATE TABLE ctrtest (a varchar, ctr counter, PRIMARY KEY(a) );
> update ctrtest set ctr=ctr+1 where a='a';
> delete from ctrtest where a='a';
> update ctrtest set ctr=ctr+1 where a='a';
> select * from ctrtest ;
> a | ctr
> ---+------
> a | null
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
