[
https://issues.apache.org/jira/browse/CASSANDRA-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627657#comment-14627657
]
Sylvain Lebresne commented on CASSANDRA-9810:
---------------------------------------------
bq. but the current behavior is the result of bug in 1.1. We should revert
CASSANDRA-7346
I don't entirely agree with your version of history :)
The current behavior was indeed initially unintended, but the point of
CASSANDRA-7346 was to say that it was probably a better behavior, so that the
current behavior is now very much on purpose. And for the record, I still
believe it's a tad more user friendly (in the sense that it makes it more clear
that counter reuse post deletion is a no go).
*That said*, counter reuse post-deletion _is_ broken, so no particular behavior
is going to be ideal and which one we implement exactly doesn't matter too
much. And so I'm fine reverting CASSANDRA-7346, at least for the reason that it
makes it impossible to do CASSANDRA-6506 properly, which is something I very
much want to see happening eventually (and more generally, the fact that
lowering the number of special case we have for counters is a good thing).
Not totally sure to see why that's a hard requirement for mixing counter and
regular column in the same table however (anything CASSANDRA-7346 is
conditioned on {{CounterCell}} as far as I can tell, not on the table having
only counters).
bq. we can start allowing to mix counters and non-counters in the same tables
I've come to peace with that idea (at least as long as we forbid mixing them in
updates). I have an ongoing worry that user will use counters in case where the
lack of idemptotency is not acceptable without realizing it, but I realize that
segregating counters to their own tables isn't a very good way to prevent that
in the first place.
> Lift some counters limitations in C* 3.X
> ----------------------------------------
>
> Key: CASSANDRA-9810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9810
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 3.x
>
>
> A ticket to aggregate issues for removal of some of the counters limitations
> we currently have:
> 1. Counters are not reusable after deletion. It's true that deletion doesn't
> commute, and an increment coming soon after a deletion would lead to
> undefined behavior, but the current behavior is the result of bug in 1.1. We
> should revert CASSANDRA-7346
> 2. Once that is done, we can start allowing to mix counters and non-counters
> in the same tables. For read requests it means data locality, being able to
> satisfy more requests with a single query. We would still be forbidding
> updating counter columns and regular columns in a single {{UPDATE}}, however,
> and would not allow counter updates in {{INSERT}}
> See CASSANDRA-8878 for some discussion of the subject. In particular,
> [this|https://issues.apache.org/jira/browse/CASSANDRA-8878?focusedCommentId=14346748&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14346748]
> and
> [this|https://issues.apache.org/jira/browse/CASSANDRA-8878?focusedCommentId=14351091&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14351091]
> comments.
> This seems to be a pre-requisite for CASSANDRA-9778.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
