[
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
