[
https://issues.apache.org/jira/browse/CASSANDRA-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5300:
----------------------------------------
Attachment: 5300-v2.txt
I'd prefer doing the validation in Operation.SetValue directly because that
where we have all the other type validation now (and it's cleaner that way
imo), as done in the attached v2.
bq. it can be very useful during table initialization/import
For the record, nobody contesting being able to set a counter would be useful.
But it doesn't work and I'm pretty sure it cannot work with the current
implementation of counters. Don't be fooled by the example above, it's not
complete. If you try an increment after the last update, you will end up with a
server side exception because you've basically corrupted your data.
> Insufficient validation of UPDATE queries against counter cfs
> -------------------------------------------------------------
>
> Key: CASSANDRA-5300
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5300
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.0
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 1.2.3
>
> Attachments: 5300.txt, 5300-v2.txt
>
>
> {noformat}
> CREATE TABLE demo (
> id int PRIMARY KEY,
> c counter
> )
> {noformat}
> This is expected:
> {noformat}
> insert into demo (id, c) VALUES ( 0, 20);
> Bad Request: INSERT statement are not allowed on counter tables, use UPDATE
> instead
> {noformat}
> This should also be forbidden, but it is not:
> {noformat}
> update demo set c = 20 where id = 0;
> select * from demo;
> id | c
> ----+----
> 0 | 20
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
