[ https://issues.apache.org/jira/browse/CASSANDRA-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196202#comment-13196202 ]
Peter Sanford commented on CASSANDRA-3710: ------------------------------------------ We hit the same issue with our integration tests. Originally we would truncate between each test. As our test suite continued to grow, the time penalty became too large for us to continue doing so. We experimented with deleting all rows from all column families instead of truncating (inspired by [this blog post][http://dev.aboutus.org/2011/08/22/cassandra-truncate-means-slow-test-suites.html]). That was faster than truncating but still not as fast as we would like (performance degraded linearly over the course of a test run). We eventually tweaked our tests in such a way that each test was guaranteed to use a new set of row keys from any previous test; effectively allowing us to ignore the problem. This was fairly simple for us because all of are row keys are prefixed with a UUID. Obviously this solution is dependent on the data model you are using and will not work for everyone. There are use cases where a patch like this would be helpful. Obviously that needs to be balanced against the cost of maintaining code that is not used in production rings. > Add a configuration option to disable snapshots > ----------------------------------------------- > > Key: CASSANDRA-3710 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3710 > Project: Cassandra > Issue Type: New Feature > Reporter: Brandon Williams > Fix For: 1.0.8 > > > Let me first say, I hate this idea. It gives cassandra the ability to > permanently delete data at a large scale without any means of recovery. > However, I've seen this requested multiple times, and it is in fact useful in > some scenarios, such as when your application is using an embedded cassandra > instance for testing and need to truncate, which without JNA will timeout > more often than not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira