The Tomstones are removed after GCGraceSeconds (in the
storage-config.xml), at the next Major Compaction
http://wiki.apache.org/cassandra/MemtableSSTable?highlight=%28tombstones%29
Take a look at http://wiki.apache.org/cassandra/DistributedDeletes and Handling Failure on http://wiki.apache.org/cassandra/Operations
This one explains the internal reason the tombstoned keys are returned http://wiki.apache.org/cassandra/FAQ#range_ghosts
You could reduce the GCGraceSeconds. Others may have a better idea how to force it.
Aaron
On 13 Jul, 2010,at 03:17 AM, Samuru Jackson <samurujack...@googlemail.com> wrote:
Hi,
I'm fairly new to Cassandra and started to set up a small cluster for
playing around and evaluating it for my potential purposes.
As far as I understand I can't remove whole rows - instead the columns
of a deleted rows are removed and a client can decided based on the
row's column count if it treats a part of a returned slice as deleted
or not. Those empty rows are referenced as a Tombstone in Cassandras
terminology- right?
Is there any way to force the sync/garbage collection of the deletion
of the such empty rows?
Reading the mailinglist, this behaviour is relating to the weak
consistency of Cassandra. What I don't understand is, why is it
possible to remove the columns of a row, but not the whole row? Could
you give me some further reading on this topic?
Thanks!
SJ
