if you violate the INSERTS ONLY contract by updating existing rows, Cassandra will give you one of those versions back when you query it, but not necessarily the most recent.
It sounds like you are saying there are no guarantees.
I've given this some thought and I think the best approach in which we can syntactically "do something" is to combine this ticket with the idea Tyler Hobbs touched on in CASSANDRA-9928. This might be what you are describing we should do but I'll just restate it.
One possible solution is to require that all non-PK columns that are in a view PK be updated simultaneously. T Jake Luciani mentioned possible problems from read repair, but it seems like, with this restriction in place, any read repairs would end up repairing all non-PK columns at once.
Basically, this would add a mode where we only allow INSERT of all columns every time. While this sounds restrictive, it also forces the user to deal with the fact that making updates conceptually/logistically hard since we would kick out all client mutations that don't specify all columns. Sure you could subvert this but to me at least, the server can alert the user that updating existing data, as they can with other tables, is hard.
So the proposal is:
- Add a table level flag/syntax to mark that a table is INSERT ONLY (which can be altered if there's an emergency).
- Reject any INSERTS/UPSERTS that do not specify all columns
- Possibly always return the earliest row if there is a conflict.
- When writing to the memtable we can add a putIfAbsent method to reject/ignore updates (to cover some minimal bases)