Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 39671 invoked from network); 7 Sep 2010 22:42:31 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 Sep 2010 22:42:31 -0000 Received: (qmail 63392 invoked by uid 500); 7 Sep 2010 22:42:29 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 63335 invoked by uid 500); 7 Sep 2010 22:42:29 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 63327 invoked by uid 99); 7 Sep 2010 22:42:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Sep 2010 22:42:28 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bburruss@real.com designates 207.188.23.4 as permitted sender) Received: from [207.188.23.4] (HELO kal-el.real.com) (207.188.23.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Sep 2010 22:42:22 +0000 Received: from seacas01.corp.real.com ([::ffff:192.168.139.56]) (TLS: TLSv1/SSLv3,128bits,AES128-SHA) by kal-el.real.com with esmtp; Tue, 07 Sep 2010 15:42:02 -0700 id 00080078.4C86BFBA.000050D7 Received: from [172.21.141.200] (192.168.198.6) by seacas01.corp.real.com (192.168.139.56) with Microsoft SMTP Server id 8.2.254.0; Tue, 7 Sep 2010 15:42:01 -0700 Message-ID: <4C86BFBA.9080703@real.com> Date: Tue, 7 Sep 2010 15:42:02 -0700 From: "B. Todd Burruss" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "user@cassandra.apache.org" Subject: Re: drop/recreate column family race condition References: <4C86A6C2.4090508@real.com> <4C86AE9E.5000705@real.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Old-Return-Path: bburruss@real.com 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 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. > >