Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of 0x6e6562@gmail.com designates
 209.85.128.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADjRqh9gZjnDsNFBoQE_ZEp+R0vw6X1SyYGAwiTHsecEWaR4Mw@mail.gmail.com>
References: 
 <CAB-G1jgGesV-u+iu31aRBu4YXbNAtZBb4tC5Va4L2j_1RhWS1Q@mail.gmail.com>
	<CABNXB2DoF5=F07PLPFNO2XexdMWU5SzuERfb3Ra7is5SYAFenA@mail.gmail.com>
	<CAB-G1jjJVa1uRU=tzvdwc_=EGMA+EkqMj1GH3H2hFT2AiTDhmA@mail.gmail.com>
	<CADjRqh9gZjnDsNFBoQE_ZEp+R0vw6X1SyYGAwiTHsecEWaR4Mw@mail.gmail.com>
Date: Wed, 26 Feb 2014 16:28:53 +0000
Message-ID: 
 <CAB-G1jhkXM6T9m56iid33sWm=aD+tOx1qwEY3tv3XLFr4u--Nw@mail.gmail.com>
Subject: Re: Flushing after dropping a column family
From: Ben Hood <0x6e6562@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 26, 2014 at 3:59 PM, Tupshin Harper <tupshin@tupshin.com> wrote:
> This is a known issue that is fixed in 2.1beta1.
> https://issues.apache.org/jira/browse/CASSANDRA-5202
>
> Until 2.1, we do not recommend relying on the recycling of tables through
> drop/create or truncate.
>
> However, on a single node cluster, I suspect that truncate will work far
> more reliably than drop/recreate.


Cool, thanks for the heads up.

Short of using 2.1beta1, is there a more stable way of recycling tables?