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 <pstanhope@wimba.com> wrote:
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:

Great! Thanks!

On Thu, Jul 1, 2010 at 3:40 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
Tombstones are internal to Cassandra and are never sent to the client.

On Thu, Jul 1, 2010 at 2:20 AM, David Boxenhorn <david@lookin2.com> wrote:
> 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.)

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support