cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jools <jool...@gmail.com>
Subject Re: Identifying Tombstones
Date Thu, 01 Jul 2010 13:44:25 GMT
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....

--Jools



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?
>
> -phil
>
> 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
>> http://riptano.com
>>
>
>
>

Mime
View raw message