[
https://issues.apache.org/jira/browse/CASSANDRA-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346748#comment-14346748
]
Sylvain Lebresne commented on CASSANDRA-8878:
---------------------------------------------
bq. What would we need to do to get rid of this distinction, then?
There isn't one single big reason for not mixing counters and normal column,
but rather a wealth of reasons that would make it awkward when not totally
confusing. More precisely:
* counters have a separate write path which is generally slower: if we have an
update that contains both counter and non-counter, we could technically send
both through the counter path, but that means the whole mutation will be as
slow as the counters. If we spend our time telling people that they should
separate counter and normal updates as much as possible to avoid slowing down
the normal ones, it's unclear we'd have win in term of user friendliness.
Having them separated make that point moot.
* counters are idempotent and people should be careful with replaying them on
timeout. Currently, having counters separated allows drivers to do the right
thing on that front, which is to automatically replay normal mutation on
timeout (when that make sense) but never replay counters update automatically.
Once we mix both, drivers can't deal with that automatically anymore and it's
generally more involved for users to deal with timeout.
* related to the previous point, logged batch don't work with counters (since
we can't guarantee we won't replay something multiple times).
* counters don't support: ttls, client-assigned timestamp, CL.ANY, LWT. When
counters are in their separate tables, refusing those is trivial. But once you
mix them in normal tables, it becomes awkward. They're also not supported in
{{INSERT}}, which if we allow counters in normal tables might push users to use
{{UPDATE}} more often than they should (ant that also create a challenge for
JSON). Deletions also don't really work well with counters, which is also imo
easier to get when counter are separated.
* More generally, counters have a fairly restricted area of application and
it's hard enough to explain users what their sweet spot actually is. I feel
that having them separated acts as a fair sign that they do are pretty special
and I'm afraid allowing mixing them with normal columns will make people abuse
them much more often (and make them miserable as a result).
Note that most of those problems are things we don't know how to fix. Others
might "maybe" be fixable, but their ratio of usefulness to complexity involved
is unlikely very good.
Of course, having things separated also makes it slightly easier on the
implementation front (in terms of validation in particular) but I don't think
that's such an important point since I don't think any code strongly rely on
that separation (at least not anymore).
At the risk of stating the obvious, I do think we should keep counters
separated (but I sure wish we had fast and reliable counters with none of those
limitations).
> 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)
