[ 
https://issues.apache.org/jira/browse/CASSANDRA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345332#comment-14345332
 ] 

Jonathan Ellis commented on CASSANDRA-8878:
-------------------------------------------

What would we need to do to get rid of this distinction, then?  It's maybe the 
ugliest wart we have left at the cql level.

> Counter Tables should be more clearly identified
> ------------------------------------------------
>
>                 Key: CASSANDRA-8878
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8878
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Michaël Figuière
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>             Fix For: 3.0
>
>
> Counter tables are internally considered as a particular kind of table, 
> different from the regular ones. This counter specific nature is implicitly 
> defined by the fact that columns within a table have the {{counter}} data 
> type. This nature turns out to be persistent over the time, that is if the 
> user do the following:
> {code}
> CREATE TABLE counttable (key uuid primary key, count counter);
> ALTER TABLE counttable DROP count;
> ALTER TABLE counttable ADD count2 int;
> {code} 
> The following error will be thrown:
> {code}
> Cannot add a non counter column (count2) in a counter column family
> {code}
> Even if the table doesn't have any counter column anymore. This implicit, 
> persistent nature can be challenging to understand for users (and impossible 
> to infer in the case above). For this reason a more explicit declaration of 
> counter tables would be appropriate, as:
> {code}
> CREATE COUNTER TABLE counttable (key uuid primary key, count counter);
> {code}
> Besides that, adding a boolean {{counter_table}} column in the 
> {{system.schema_columnfamilies}} table would allow external tools to easily 
> differentiate a counter table from a regular one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to