[
https://issues.apache.org/jira/browse/CASSANDRA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345310#comment-14345310
]
Sylvain Lebresne commented on CASSANDRA-8878:
---------------------------------------------
Afaik, none of reasons for no allowing mixing counter and non-counter will be
removed by splitting counters in cells, so that wouldn't change anything for
this issue.
> 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)
