When using cassandra , your first part of the primary key becomes the partition key. Hence , to go to a particular partition for retrieving the row, you need to specify the primary key with equals constraint always.
select * from tax_keyspace_dev.chat_messages where participants='caone@one.com_shashank_shrivastava@acme.com' order by when;
The following query suggests that you arrive at your row partition named "participants" and then you order by when using default ordering of ASC.This order by may not be needed too as your columns are by default ordered in ascending order.
select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;
select * from tax_keyspace_dev.chat_messages where to_id='caone@one.com' order by when;
Following query doesnt work as you are not providing the row partition to locate the value.By default, the row partition keys are used to identify the SSTables that contain the data . So, by default , cassandra doesnt support this costly operation.
What happens is simple. If you miss this row partition key, cassandra has to scan through all SSTables and get the data out of it. That can be done by using ALLOW FILTERING but your query becomes expensive as it will not be using bloom filter.
update tax_keyspace_dev.chat_messages set read=true where participants = 'caone@one.com_shashank_shrivastava@acme.com' and when = '2014-04-10 17:44:22+0530';
In case of updates on cassandra, its not different from inserts. Just consider a case of operating with maps. You are trying to modify a value but you dont have the complete key for the map. Internally, cassandra stores the values are "participants_when_to_id": value.