Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 82589 invoked from network); 6 May 2010 16:27:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 May 2010 16:27:00 -0000 Received: (qmail 40574 invoked by uid 500); 6 May 2010 16:26:59 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 40553 invoked by uid 500); 6 May 2010 16:26:59 -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 40545 invoked by uid 99); 6 May 2010 16:26:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 May 2010 16:26:59 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of greenemj@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 May 2010 16:26:53 +0000 Received: by pvg13 with SMTP id 13so65248pvg.31 for ; Thu, 06 May 2010 09:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=eXR7LAnB2PUTjKtoqh3xq17A6MTMSCGgtSq9xDd3Wrs=; b=msHn6jYN68fkTvlplIzuh7p3veKWGqDgEH3OqFJ/vYygChsEN1tUHuYZK15N/oi7aL lz6HLxgfEcLFVL7RSfs8LZvOdnXPu7gK3+wKqYN6kWVkg9ra5vynRlK0JFmmEdngfRUz d3a5Vc+NqCy6ets2qA2vnf3+r/pNK6LtJkv9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=bHLtE3dAyZ42Nq+umlwh05h9UILDvgzOB/Ja0o7h4Lwa/wQ/XdejCuW8Vfqp+Yy4eA fI8xAC655h6cs3KBykcHSuMVlRWHA23ZAMPlKydgj+zriRNDRXR+Kb9Y0rosg5GcEuLI oB4qGl/Xf7+RlIuADT3/CbqXb1wt0SBnlMDek= Received: by 10.140.248.10 with SMTP id v10mr6922640rvh.245.1273163193131; Thu, 06 May 2010 09:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.17 with HTTP; Thu, 6 May 2010 09:26:13 -0700 (PDT) In-Reply-To: References: From: Mark Greene Date: Thu, 6 May 2010 12:26:13 -0400 Message-ID: Subject: Re: pagination through slices with deleted keys To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=000e0cd0ed46de24790485ef6717 --000e0cd0ed46de24790485ef6717 Content-Type: text/plain; charset=ISO-8859-1 Hey Ian, I actually just wrote a quick example of how to iterate over a CF that may have tombstones. This may help you out: http://markjgreene.wordpress.com/2010/05/05/iterate-over-entire-cassandra-column-family/ On Thu, May 6, 2010 at 12:17 PM, Ian Kallen wrote: > I read the DistributedDeletes and the range_ghosts FAQ entry on the wiki > which do a good job describing how difficult deletion is in an eventually > consistent system. But practical application strategies for dealing with it > aren't there (that I saw). I'm wondering how folks implement pagination in > their applications; if you want to render N results in an application, is > the only solution to over-fetch and filter out the tombstones? Or is there > something simpler that I overlooked? I'd like to be able to count (even if > the counts are approximate) and fetch rows with the deleted ones filtered > out (without waiting for the GCGraceSeconds interval + compaction) but from > what I see so far, the burden is on the app to deal with the tombstones. > -Ian > --000e0cd0ed46de24790485ef6717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Ian,

I actually just wrote a quick example of how to= iterate over a CF that may have tombstones. This may help you out:=A0http://markjgreene.wordpress.com/2010/05/05/iterate-ov= er-entire-cassandra-column-family/

On Thu, May 6, 2010 at 12:17 PM, Ian Kallen = <spidaman.l= ist@gmail.com> wrote:
I read the DistributedDeletes and the range_ghosts FAQ entry on the wiki wh= ich do a good job describing how difficult deletion is in an eventually con= sistent system. But practical application strategies for dealing with it ar= en't there (that I saw). I'm wondering how folks implement paginati= on in their applications; if you want to render N results in an application= , is the only solution to over-fetch and filter out the tombstones? Or is t= here something simpler that I overlooked? I'd like to be able to count = (even if the counts are approximate) and fetch rows with the deleted ones f= iltered out (without waiting for the GCGraceSeconds interval + compaction) = but from what I see so far, the burden is on the app to deal with the tombs= tones.
-Ian

--000e0cd0ed46de24790485ef6717--