Just a short note to add....
If you delet a key, and it has not been removed via a flush and compaction, it will be returned as a key with no (super)column(s) from a get_range_slices call.
Should you try to write to the same column family using the same key as a tombstone, it will be silently ignored. Something I've now worked around, but it did cause me a few issues to start with.
Hope it helps....
On 1 July 2010 14:35, Phil Stanhope <email@example.com>
I understand that tombstones are internal implementation detail ... yet, the fact remains in 0.6.2 that a key/col creation followed by a delete of the key/col will result in the key being returned in a get_range_slices call. If the CF is flushed and compacted (after GCGraceSeconds), the key will not be returned in the get_range_slices call.
David ... is this what you are referring to?
Is there anyway to tell get_range_slices to return only keys that have a (any) column?
On Jul 1, 2010, at 9:03 AM, David Boxenhorn wrote:
On Thu, Jul 1, 2010 at 3:40 PM, Jonathan Ellis <firstname.lastname@example.org>
Tombstones are internal to Cassandra and are never sent to the client.
On Thu, Jul 1, 2010 at 2:20 AM, David Boxenhorn <email@example.com
> I recently learned that when I get a key, I might get a tombstone.
> How can I know if a returned key is a tombstone? (I need to ignore them for
> my application.)
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support