>From the code, it appears that for "get" the default is ONE. Column column = thriftClient_.get(tableName, key, path, ConsistencyLevel.ONE).column - m.
On Thu, Feb 25, 2010 at 11:08 AM, Masood Mortazavi < masoodmortaz...@gmail.com> wrote: > > > What is the write and read consistency level for the CLI tool > "cassandra-cli" ? > > Do the "set" and "get" commands in the "cli" allow the Consistency Level to > be specified for a given "set" or "get"? > > Is there a current specification of CLI anywhere on the wiki? > > ( How are JIRA's related to the CLI tagged in the JIRA system assuming they > are "tagged" separately? In other words, is there an identifier for them? ) > > Regards, > m. > > ========================== > The Cassandra "API" describes write and read consistency levels as follows: > http://wiki.apache.org/cassandra/API > Write > > *Level* > > *Behavior* > > ZERO > > Ensure nothing. A write happens asynchronously in background > > ANY > > (Coming in 0.6) Ensure that the write has been written to at least 1 node, > including hinted recipients. > > ONE > > Ensure that the write has been written to at least 1 node's commit log and > memory table before responding to the client. > > QUORUM > > Ensure that the write has been written to <ReplicationFactor> / 2 + 1nodes > before responding to the client. > > ALL > > Ensure that the write is written to all <ReplicationFactor> nodes before > responding to the client. Any unresponsive nodes will fail the operation. > > Read > > *Level* > > *Behavior* > > ZERO > > Not supported, because it doesn't make sense. > > ANY > > Not supported. You probably want ONE instead. > > ONE > > Will return the record returned by the first node to respond. A consistency > check is always done in a background thread to fix any consistency issues > when ConsistencyLevel.ONE is used. This means subsequent calls will have > correct data even if the initial read gets an older value. (This is called > read repair.) > > QUORUM > > Will query all storage nodes and return the record with the most recent > timestamp once it has at least a majority of replicas reported. Again, the > remaining replicas will be checked in the background. > > ALL > > Will query all storage nodes and return the record with the most recent > timestamp once all nodes have replied. Any unresponsive nodes will fail the > operatio > >
