> Some 'feature' for future implementation, maybe?
imho truncation working as a meta data operation is the correct approach. It's
generally used in testing and development. It deletes the data and removes the
SSTables, giving you a clean state.
A CF level tombstone would mean that reads had to
Check, I understand. Thanks!
The cluster certainly was overloaded and I did not realize that truncate
does not tombstone or have a timestamp. Some 'feature' for future
implementation, maybe?
It seems odd if you expect the same behaviour of "delete from usertable"
(in SQL, not yet in CQL, I presume
I don't know the YCSB code, but one theory would be…
1) The cluster is overloaded by the test.
2) A write at CL ALL fails because a node does not respond in time.
3) The coordinator stores the hint and returns failure to the client.
4) The client gets an UnavailableException and retries the ope
Hi guys,
I got a weird thingy popping up twice today, I run a test where I insert
a milion records via YCSB and edited it to allow me to adjust the
consistency level: the write operations are done with ConsistencyLevel.ALL.
This is send to a 4 (virtual) node cluster with a keyspace 'test' set up
w
