Difference between Destroy and Delete

Question

What is the difference between    model destroy and  model delete   For example   Model find by col   foo   destroy all   and Model find by col   foo   delete all   Does it really matter if I use the one or the other

User · Answer

Yes there is a major difference between the two methods Use delete_all if you want records to be deleted quickly without model callbacks being called

If you care about your models callbacks then use destroy_all

From the official docs

http://apidock.com/rails/ActiveRecord/Base/destroy_all/class

destroy_all(conditions = nil) public

Destroys the records matching conditions by instantiating each record and calling its destroy method. Each object’s callbacks are executed (including :dependent association options and before_destroy/after_destroy Observer methods). Returns the collection of objects that were destroyed; each will be frozen, to reflect that no changes should be made (since they can’t be persisted).

Note: Instantiation, callback execution, and deletion of each record can be time consuming when you’re removing many records at once. It generates at least one SQL DELETE query per record (or possibly more, to enforce your callbacks). If you want to delete many rows quickly, without concern for their associations or callbacks, use delete_all instead.

User · Answer

When you invoke destroy or destroy all on an ActiveRecord object  the ActiveRecord  destruction  process is initiated  it analyzes the class you re deleting  it determines what it should do for dependencies  runs through validations  etc   When you invoke delete or delete all on an object  ActiveRecord merely tries to run the DELETE FROM tablename WHERE conditions query against the db  performing no other ActiveRecord-level tasks

User · Answer

delete will only delete current object record from db but not its associated children  records from db   destroy will delete current object record from db and also its associated children  record from db   Their use really matters   If your multiple parent objects share common children objects  then calling destroy on specific parent object will delete children objects which are shared among other multiple parents

User · Answer

Basically destroy runs any callbacks on the model while delete doesn t   From the Rails API    ActiveRecord  Persistence delete     Deletes the record in the database and freezes this instance to reflect that no changes should be made  since they can t be persisted   Returns the frozen instance       The row is simply removed with an SQL DELETE statement on the record s primary key  and no callbacks are executed       To enforce the object s before destroy and after destroy callbacks or any  dependent association options  use  destroy   ActiveRecord  Persistence destroy     Deletes the record in the database and freezes this instance to reflect that no changes should be made  since they can t be persisted        There s a series of callbacks associated with destroy  If the before destroy callback return false the action is cancelled and destroy returns false  See ActiveRecord  Callbacks for further details

User · Answer

A lot of answers already  wanted to jump on with a bit more   docs      For has many  destroy and destroy all will always call the destroy method of the record s  being removed so that callbacks are run  However delete and delete all will either do the deletion according to the strategy specified by the  dependent option  or if no  dependent option is given  then it will follow the default strategy  The default strategy is to do nothing  leave the foreign keys with the parent ids set   except for has many  through  where the default strategy is delete all  delete the join records  without running their callbacks     The delete verbage works differently for ActiveRecord  Association has many and ActiveRecord  Base  For the latter  delete will execute SQL DELETE and bypass all validations callbacks  The former will be executed based on the  dependent option passed into the association  However  during testing  I found the following side effect where callbacks were only ran for delete and not delete all  dependent   destroy Example    class Parent  lt  ApplicationRecord    has many  children       before remove  - gt        puts  before remove callback          dependent   destroy end  class Child  lt  ApplicationRecord    belongs to  parent     before destroy - gt    puts  before destroy callback    end   gt  child delete                              Ran without callbacks Child Destroy  99 6ms   DELETE FROM  children  WHERE  children   id     1     id   21     gt  parent children delete other child        Ran with callbacks before remove callback before destroy callback Child Destroy  0 4ms   DELETE FROM  children  WHERE  children   id     1     id   22     gt  parent children delete all                Ran without callbacks Child Destroy  1 0ms   DELETE FROM  children  WHERE  children   parent id     1     parent id   1

User · Answer

Basically  delete  sends a query directly to the database to delete the record  In that case Rails doesn t know what attributes are in the record it is deleting nor if there are any callbacks  such as before destroy    The  destroy  method takes the passed id  fetches the model from the database using the  find  method  then calls destroy on that  This means the callbacks are triggered   You would want to use  delete  if you don t want the callbacks to be triggered or you want better performance  Otherwise  and most of the time  you will want to use  destroy

[ruby-on-rails] Difference between Destroy and Delete

Examples related to ruby-on-rails

Examples related to destroy

Examples related to delete-row