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 <pstanh...@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 <jbel...@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 <da...@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 >> > > >
