Cool, is this a patch you've applied on the server side? Are you running 0.6.x? I'm wondering if this kind of thing can make it into future versions of Cassandra. -Ian
On Thu, May 6, 2010 at 2:56 PM, Mike Malone <m...@simplegeo.com> wrote: > Our solution at SimpleGeo has been to hack Cassandra to (optionally, at > least) be sensible and drop Rows that don't have any Columns. The claim from > the FAQ that "Cassandra would have to check if there are any other columns > in the row" is inaccurate. The common case for us at least is that we're > only interested in Rows that have Columns matching our predicate. So if > there aren't any, we just don't return that row. No need to check if the > entire row is deleted. > > Mike > > > On Thu, May 6, 2010 at 9:17 AM, Ian Kallen <spidaman.l...@gmail.com>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 >> > >
