Why does ActiveRecord provide .delete_all and not .truncate?

It seems strange that I have to manually execute SQL to use the TRUNCATE command. Is there something bad about it that DHH is p开发者_StackOverflowrotecting me against?

Using TRUNCATE on some databases does not run triggers. Using DELETE for each row will still run triggers. TRUNCATE also cannot be rolled back, so if you did a .destroy_all in a transaction, it would erase all the data even if you tried to rollback.

So, yes, you are being protected against the effects of truncate.

Assuming you're using MySQL or Postgre and not SQlite3 (which doesn't support TRUNCATE), you could add the following method to your model.

def self.truncate
  self.connection_pool.with_connection { |c| c.truncate(table_name) }
end

Note that this would not invoke ActiveRecord callbacks. There are better ways to do this that don't tie your code to a specific DB implementation, but even this is better than writing the SQL yourself.

There are many use cases for TRUNCATE, and in my opinion, the answers given here are very insufficient. Using Postgres as an example:

• TRUNCATE is definitely transaction safe in some RDBMS, as already noted by jsears. It can be rolled back, at least in Postgres. Isn't Rails supposed to be db-agnostic and allow for such things?
• TRUNCATE will also execute BEFORE TRUNCATE or AFTER TRUNCATE triggers in Postgres. If you are expecting a DELETE trigger to fire on TRUNCATE that's your design fault!
• TRUNCATE performs far quicker than DELETE especially for large datasets because it's a single short DDL statement.
• In Postgres' MVCC architecture, TRUNCATE removes all index and table bloat.

For these reasons it's crazy to me that Rails does not support TRUNCATE. No, I don't think the reasons given are good ones.

Take a look at Model.destroy_all and active record : dependent => :destroy relations. If you don't specify :dependent => :destory, some of the defaults is to set relation to null but not destroy the record.