Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B4A64964C for ; Wed, 28 Mar 2012 11:15:05 +0000 (UTC) Received: (qmail 43187 invoked by uid 500); 28 Mar 2012 11:15:03 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 43123 invoked by uid 500); 28 Mar 2012 11:15:03 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 43115 invoked by uid 99); 28 Mar 2012 11:15:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 11:15:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ross.w.black@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vb0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 11:14:57 +0000 Received: by vbbez10 with SMTP id ez10so693956vbb.31 for ; Wed, 28 Mar 2012 04:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MVfLRF/FzInshvCdzLdOd7n6iF/1xBl7pd6PXQbWVZo=; b=fKopsaXFmyk1SvP0fZ2+spjXQV7M9mJNnMY4PL/o2bd2a7KqkpBgRjw+nkk1neARkh zYghgRJLx54Q10NLUJ5pR/5etfUxIUBM7krdCP/OUS0UJUKggbdeHvx1BJfprPWbw+YM 7L9AzVA7jTd0Zs3RLHSv5CcTUMimpaz8Rc2jlVQrfXPL2+F4BHLcqssouJ6+97glAf0w 8ixgle7HrlMcs9kH93ELk42ccIxJt8tPuYeJWlFGTc16Qyz75y0uRro7YHa9780HFhix kzl2FX0Gx1Zh9B7G/pDUr4EnKj9XjaoMz/nZBu7+OgdYZVejMlR2flUIIbWURXMy0k+Q XhYA== MIME-Version: 1.0 Received: by 10.220.156.72 with SMTP id v8mr1693815vcw.45.1332933276326; Wed, 28 Mar 2012 04:14:36 -0700 (PDT) Received: by 10.52.165.232 with HTTP; Wed, 28 Mar 2012 04:14:36 -0700 (PDT) In-Reply-To: References: <2C85E14562B39345BCCAD90B8E7955C90BD433@DKEXC001.adform.com> <2C85E14562B39345BCCAD90B8E7955C90BDD77@DKEXC001.adform.com> <4F6C34EB.2050205@filez.com> <2C85E14562B39345BCCAD90B8E7955C90BDE58@DKEXC001.adform.com> <4F6C5E36.1010009@filez.com> <2C85E14562B39345BCCAD90B8E7955C90BE120@DKEXC001.adform.com> <4F6EF13B.3050104@filez.com> <2C85E14562B39345BCCAD90B8E7955C90BE421@DKEXC001.adform.com> <4F7186AE.5080203@filez.com> Date: Wed, 28 Mar 2012 22:14:36 +1100 Message-ID: Subject: Re: tombstones problem with 1.0.8 From: Ross Black To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=f46d043c7fb271d96e04bc4bb62e --f46d043c7fb271d96e04bc4bb62e Content-Type: text/plain; charset=ISO-8859-1 Radim, We are only deleting columns. *Rows are never deleted.* We are continually adding new columns that are then deleted. * Existing columns (deleted or otherwise) are never updated. * Ross* * On 28 March 2012 13:51, John Laban wrote: > (Radim: I'm assuming you mean "do not delete already deleted columns" as > Ross doesn't delete his rows.) > > Just to be clear about Ross' situation: he continually inserts columns > and later deletes columns from the same set of rows. As long as he * > doesn't* *keep deleting already-deleted columns* (which refreshes the > tombstone on them), the deleted columns *should* get cleaned up, right? > (Even though the row itself continually gets new columns inserted and > other columns deleted?) > > Thanks, > John > > > > > On Tue, Mar 27, 2012 at 2:21 AM, Radim Kolar wrote: > >> Dne 27.3.2012 11:13, Ross Black napsal(a): >> >> Any pointers on what I should be looking for in our application that >>> would be stopping the deletion of tombstones? >>> >> do not delete already deleted rows. On read cassandra returns deleted >> rows as empty in range slices. >> > > --f46d043c7fb271d96e04bc4bb62e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Radim,

We are only deleting columns.=A0 Rows are never deleted.
We are continually adding new columns that are then deleted.=A0 Ex= isting columns (deleted or otherwise) are never updated.

Ross=


On 28 March 2012 13:51, John Laban <= span dir=3D"ltr"><john@pagerduty.c= om> wrote:
(Radim: =A0I'm assuming you mean "do not delete already delet= ed columns" as Ross doesn't delete his rows.)

= Just to be clear about Ross' situation: =A0he continually inserts colum= ns and later deletes columns from the same set of rows. =A0As long as he doesn't
=A0keep deleting already-deleted columns=A0(which re= freshes the tombstone on them), the deleted columns should get clean= ed up, right? =A0(Even though the row itself continually gets new columns i= nserted and other columns deleted?)

Thanks,
John




On Tue, Mar 27, 2012 at 2= :21 AM, Radim Kolar <hsn@filez.com> wrote:
Dne 27.3.2012 11:13, Ross= Black napsal(a):

Any pointers on what I should be looking for in our application that would = be stopping the deletion of tombstones?
do not delete already deleted rows. On read cassandra returns deleted rows = as empty in range slices.


--f46d043c7fb271d96e04bc4bb62e--