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> 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
>
smime.p7s
Description: S/MIME cryptographic signature
