kotovalexarian-likes-github/database_cleaner
1
0
Fork 0
mirror of https://github.com/DatabaseCleaner/database_cleaner synced 2023-03-27 23:22:03 -04:00
Code Releases Activity

Fix a typo in README.

Browse source
This commit is contained in:
Ryota Arai 2013-04-19 14:49:10 +09:00
parent 7c3fadd6f6
commit f70eceec6e
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.markdown
View file

@ -98,7 +98,7 @@ Another approach is to have the transactions rolled back in the application's pr
An easier, but slower, solution is to use the `:truncation` or `:deletion` strategy. An easier, but slower, solution is to use the `:truncation` or `:deletion` strategy.
So what is fastest out of `:deletion` and `:truncation`? Well, it depends on your table structure and what percentage of tables you populate in an average test. The reasoning is out the the scope of this README but here is a [good SO answer on this topic for Postgres](http://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886#11423886). So what is fastest out of `:deletion` and `:truncation`? Well, it depends on your table structure and what percentage of tables you populate in an average test. The reasoning is out of the scope of this README but here is a [good SO answer on this topic for Postgres](http://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886#11423886).
Some people report much faster speeds with `:deletion` while others say `:truncation` is faster for them. The best approach therefore is it try all options on your test suite and see what is faster. Some people report much faster speeds with `:deletion` while others say `:truncation` is faster for them. The best approach therefore is it try all options on your test suite and see what is faster.