truncate doesn't change schema, it just drops the data associated with it. so it's a different beast from either normal writes or schema change.
truncate will wait for each node to response, and send a TimedOutException if any do not. On Tue, Sep 7, 2010 at 5:42 PM, B. Todd Burruss <bburr...@real.com> wrote: > interesting is that "truncate" API doesn't return a schema version nor take > a consistency level. does this mean that when it returns the cluster is > always consistent? > > On 09/07/2010 02:50 PM, Jonathan Ellis wrote: >> >> On Tue, Sep 7, 2010 at 4:29 PM, B. Todd Burruss<bburr...@real.com> wrote: >> >>> >>> if you are referring to R, W, N - i am aware, but i have a one node >>> cluster, >>> with R=W=N = 1. single threaded test app. any column manipulations >>> would >>> be immediate because R+W>N, so i assume the same for column family >>> manipulations. is this an invalid assumption? >>> >> >> Gary can correct me if I'm wrong, but schema change is always >> asynchronous as you can tell by having no ConsistencyLevel associated >> with the calls. You need to call check_schema_agreement to make sure >> that the nodes are on the version returned by the migration call. >> >> > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
