Why can cassandra "select" on secondary key, but not update using secondary key? (1.2.8+)

Question

Assuming this table:

create table s4 (a timeuuid primary key, b timeuuid, stuff text);
create index s4_index1 on s4 (b);

This works:

select * from s4 where b = 259300f1-01bb-11e3-89a8-896ab45a266f;

But this fails. Why? And how do I work around it?

update s4 set stuff='f' where b=259300f1-01bb-11e3-89a8-896ab45a266f;
error->> Bad Request: Non PRIMARY KEY b found in where clause

Answer 1

Doing an update without specifying the primary key would mean Cassandra would have to first do the distributed search to get all of the records. Then internally issue the update for all of those records. While it would be possible to implement, it is very different from the current write path inside Cassandra.

The current write path looks at the insert/update figures out what nodes it should be sent to based on the key, then sends the request on to those nodes to be written to disk.

The write path for update X where Y, where Y is a secondary index, would be much different. It would require sending the update request to every node, and waiting for the search/update process to finish. It would take much longer than a normal write, and Cassandra excels at fast writes.

That being said, the Cassandra project is always open to contributions and discussion of new features. http://wiki.apache.org/cassandra/HowToContribute

For "How do I work around it". The only way is to perform the select statement yourself, and then update all the rows yourself. Or redesign your data model such that the update you want to do is based on a primary key.