Thanks Mark, great illustration. I'm already splitting my time developing directly with hector and a vastly simplified jython wrapper around it; I guess I'll address it at some wrapping layer (patch hector or let the jython layer deal).
My grumpy editorial about this stuff is that on the cassandra server, the Column has an isMarkedForDelete():boolean and the thrift (+avro) API could (should) expose the ability to filter the true cases. It seems pretty grotty to allow such low level data bookkeeping to leak into the application space; analogous to the ConsistencyLevel and timestamp stuff that most folks don't need on the app layer, slicing via the service API should do the filtering unless your abstraction actually *needs* the tombstones. OK, done being grumpy :) -Ian On Thu, May 6, 2010 at 9:26 AM, Mark Greene <green...@gmail.com> wrote: > 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 <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 >> > >
