The simplest breakdown: destroy runs any callbacks and delete doesn't. What all does that mean though? Why are there two different functions? When do you implement them? How do you know when to implement the different functions? Does it really matter??
Well. The answer to all of those questions is incredibly nuanced once you really get into it. But the answer to the most important one of "does it matter?" is Yes. It really does. Lets start with delete.
What does delete do?
In the most basic terms I can possibly write, delete just removes the selected SQL row and then returns the number of rows deleted. There is no behind the scenes. You just remove the data from the database.
Now... What does destroy do?
Destroy, on top of removing the selected SQL row fires off all of the callbacks and filters before the object(s) is deleted and it also removes the specific ID(s) from the table. It essentially creates a new object from the attributes and then calls destroy on it.
While destroy is less efficient than delete because it fires off callbacks and filters, such things are necessary in certain instances because all of those methods being called allows for cleanup methods to work their magic.
Even though it seems like it it would make more sense to use destroy all the time, you can and should use delete if you want your object to be removed more quickly buuuut, you should absolutely use destroy if you care about your validations and your callbacks. It might run slower but it will make things easier for you in the long run. Like everything with code use common sense and ask questions! There is no one right answer to anything!
Top comments (0)