2.0.16 I could argue that either way is correct. It’s just disconcerting that the behavior changed. I spent some time and found and fixed everywhere in my code where this change could be a problem, and I fixed it in such a way that if works for both behaviors. I’d hate for this to come back to bite me if I upgrade again and the behavior reverts back to how 2.0 works.
I recently found a very simple and 100% reproducible paging bug in 2.0.16 related to static columns (you get a duplicate row at page boundaries 100% of the time with a simple select by partition key). Even though static columns have existed for some time, it seems perhaps they aren’t fully baked. Robert On Dec 3, 2015, at 10:18 PM, Graham Sanderson <gra...@vast.com<mailto:gra...@vast.com>> wrote: You didn’t specify which version of 2.0 you were on. There were a number of inconsistencies with static columns fixed in 2.0.10 for example CASSANDRA-7490, and CASSANDRA-7455, but there were others, and the same bugs may have caused a bunch of other issues. It very much depends exactly how you insert data (and indeed I believe is a rare case where an UPDATE is not equivalent to an INSERT) whether a partition exists when it only has static columns. The behavior you see does make sense though, in that it should be possible to insert static data only, and thus at the partition key must exist (so it is entirely reasonable to create CQL rows which have no actual - i.e. all null - values). Taking it a step further if you have TTL on all non static (clustering and data) columns, you don’t (necessarily) want the static data to disappear when the other cells do - though you can achieve this with statement wide TTL-ing on insertion of the static data. On Dec 3, 2015, at 6:31 PM, Robert Wille <rwi...@fold3.com<mailto:rwi...@fold3.com>> wrote: With this schema: CREATE TABLE roll ( id INT, image BIGINT, data VARCHAR static, PRIMARY KEY ((id), image) ) WITH gc_grace_seconds = 3456000 AND compaction = { 'class' : 'LeveledCompactionStrategy', 'sstable_size_in_mb' : 160 }; if I run SELECT image FROM roll WHERE id = X on 2.0, where partition X has only static data, no rows were returned. In 2.1.11, it returns one row with a null value. Was this change in behavior intentional? Is there an option to get the old behavior back? I potentially have broken code anywhere that I access a table with a static column. Kind of a mess, and not the kind of thing a person expects when upgrading. Thanks Robert
