>>- support for atomic operations or batches (if QUORUM fails, data should not be visible with ONE) >zookeeper is solving that.
Yeah, I can use HBase too. I might have screwed up a little bit since I didn't talk about isolation; let's reformulate: support for read committed (using DB terminology). Cassandra is more like read uncommitted. Even if row mutations in one CF for one key are atomic on one server , stuff is not rolled back when the CL can't be satisfied at the coordinator level. Data won't be visible at QUORUM level, but when using weaker CL, invalid data can appear imho. Also it should be possible to tell which operations failed with batch_mutate but unfortunately it is not. HBase has a clear semantic on mutations (http://hbase.apache.org/acid-semantics.html), maybe a similar page could be written to tell the way Cassandra is handling this. I don't know if some materials already exists in the wiki, but I can try to write something about this. Anyway, all in all, I'd like to see read committed appears at some point in Cassandra. The way Cassandra is working might render this a bit hard to introduce - but anyway, I'm just expressing my own feedback on this even if this is far away from the weak consistency Cassandra offer. >> - TTL on CF, rows and counters > TTL on counters will be nice, but i am good with rest as it is Actually, counters have to be handle specifically to work around the non TTL support. This would be nice to unify storage capabilities. While talking about counters, I will add to the wish list the capability to mix normal columns with counter columns in the same CF allowing easy dropping of a row or atomic mutations on one row.
