[
https://issues.apache.org/jira/browse/CASSANDRA-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112106#comment-14112106
]
Aleksey Yeschenko commented on CASSANDRA-7831:
----------------------------------------------
Okay. 2.0 behaves like this because for several C* version we've mistakenly
used millisecond-precision timestamps for counter cells. The timestamp of a
column drop, however, is correctly recorded in microseconds. So, a dropped
counter column on 2.0, if recreated, will never work. This was fixed in
CASSANDRA-7346.
And it doesn't entirely work with 2.1 (includes the previous value), because
removing dropped columns from the read values happens after reconcile, and
counters reconcile differently from regular cells.
There is no good fix for 2.0 (aside from special-casing counters and do an
extra / 1000 division, but that would give you wrong results during 2.0->2.1
upgrade, which is unacceptable).
So until maybe we push dropped columns machinery deeper in the storage engine,
I suggest simply rejecting ALTER TABLE ADD if a column with this name had been
dropped in the past.
> recreating a counter column after dropping it leaves in unusable state
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-7831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7831
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Peter Mädel
>
> create table counter_bug (t int, c counter, primary key (t));
> update counter_bug set c = c +1 where t = 1;
> select * from counter_bug ;
>
> t | c
> ---+---
> 1 | 1
>
> (1 rows)
>
> alter table counter_bug drop c;
> alter table counter_bug add c counter;
> update counter_bug set c = c +1 where t = 1;
> select * from counter_bug;
>
> (0 rows)
> update counter_bug set c = c +1 where t = 2;
> select * from counter_bug;
>
> (0 rows)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
