cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: drop/recreate column family race condition
Date Tue, 07 Sep 2010 22:51:05 GMT
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 <bburruss@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<bburruss@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

Mime
View raw message