cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Sanderson <>
Subject Re: Behavior difference between 2.0 and 2.1
Date Fri, 04 Dec 2015 05:18:05 GMT
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 <> wrote:
> With this schema:
> 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

View raw message