This issue really needs to be strongly highlighted in the documentation. Imagine someone noticing similarities between SQL and CQL and assuming that one could actually drop a table and recreate the table as a method of deleting all the data...totally crazy, I know...
On Fri, May 22, 2015 at 11:06 AM, Walsh, Stephen <stephen.wa...@aspect.com> wrote: > Thanks for the link, > > > > I don’t think your link is what I hand mind – considering it mentioned to > be fixed in 2.0.13 > > > > I was referring to this “won’t fix” issue > > https://issues.apache.org/jira/browse/CASSANDRA-4857 > > > > We’ve seen this a few times, we’re we drop a key space and re-create it > and get inconstancy issues. > > It even happened to me mid Message thread on these boards. > > > > http://www.mail-archive.com/user%40cassandra.apache.org/msg42139.html > > > > > > > > *From:* Sebastian Estevez [mailto:sebastian.este...@datastax.com] > *Sent:* 22 May 2015 14:46 > > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > I’m aware of issues where recreating key spaces can cause inconsistency > in 2.0.13 if memTables are not flushed beforehand , is this the issues that > is resolved? > > > > Yep, that's https://issues.apache.org/jira/browse/CASSANDRA-7511 > > > All the best, > > > > *[image: datastax_logo.png] <http://www.datastax.com/>* > > Sebastián Estévez > > Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com > > [image: linkedin.png] <https://www.linkedin.com/company/datastax>[image: > facebook.png] <https://www.facebook.com/datastax>[image: twitter.png] > <https://twitter.com/datastax>[image: g+.png] > <https://plus.google.com/+Datastax/about> > <http://feeds.feedburner.com/datastax> > > > <http://cassandrasummit-datastax.com/> > > > > DataStax is the fastest, most scalable distributed database technology, > delivering Apache Cassandra to the world’s most innovative enterprises. > Datastax is built to be agile, always-on, and predictably scalable to any > size. With more than 500 customers in 45 countries, DataStax is the > database technology and transactional backbone of choice for the worlds > most innovative companies such as Netflix, Adobe, Intuit, and eBay. > > > > On Fri, May 22, 2015 at 7:53 AM, Walsh, Stephen <stephen.wa...@aspect.com> > wrote: > > Can someone share the content on this link please, I’m aware of issues > where recreating key spaces can cause inconsistency in 2.0.13 if memTables > are not flushed beforehand , is this the issues that is resolved? > > > > > > *From:* Ken Hancock [mailto:ken.hanc...@schange.com] > *Sent:* 21 May 2015 17:13 > *To:* user@cassandra.apache.org > *Subject:* Re: Drop/Create table with same CF Name > > > > Thanks Mark (though that article doesn't appear publicly accessible for > others). > > Truncate would have been the tool of choice, however my understanding is > truncate fails unless all nodes are up and running which makes it a > non-workable choice since we can't determine when failures will occur. > > Ken > > > > On Thu, May 21, 2015 at 11:00 AM, Mark Reddy <mark.l.re...@gmail.com> > wrote: > > Yes, it's a known issue. For more information on the topic see this > support post from DataStax: > > > > > https://support.datastax.com/hc/en-us/articles/204226339-How-to-drop-and-recreate-a-table-in-Cassandra-versions-older-than-2-1 > > > Mark > > > > On 21 May 2015 at 15:31, Ken Hancock <ken.hanc...@schange.com> wrote: > > > > We've been running into the reused key cache issue (CASSANDRA-5202) with > dropping and recreating the same table in Cassandra 1.2.18 so we've been > testing with key caches disabled which does not seem to solve the issue. > In the latest logs it seems that old SSTables metadata gets read after the > tables have been deleted by the previous drop, eventually causing an > exception and the Thrift interface shut down. > > At this point is it a known issue that one CANNOT reuse a table name prior > to Cassandra 2.1 ? > > > > > > > > This email (including any attachments) is proprietary to Aspect Software, > Inc. and may contain information that is confidential. If you have received > this message in error, please do not read, copy or forward this message. > Please notify the sender immediately, delete it from your system and > destroy any copies. You may not further disclose or distribute this email > or its attachments. > > > This email (including any attachments) is proprietary to Aspect > Software, Inc. and may contain information that is confidential. If you > have received this message in error, please do not read, copy or forward > this message. Please notify the sender immediately, delete it from your > system and destroy any copies. You may not further disclose or distribute > this email or its attachments. >
