Why were the words delete & destroy chosen for those particular operations? It always seems to me that they're the wrong way round - 'delete' sounds like a careful removal, whereas 'destroy' sounds like wanton removal without regard for the aftereffects. Are there legacy reasons for the choice?
Jon
Jonathan del Strother wrote:
Why were the words delete & destroy chosen for those particular
operations? It always seems to me that they're the wrong way round -
'delete' sounds like a careful removal, whereas 'destroy' sounds like
wanton removal without regard for the aftereffects. Are there legacy
reasons for the choice?
Think that "delete" comes from low level sql command "DELETE", i.e. dumb removal without any intervention from rails.
Zsombor
Why were the words delete & destroy chosen for those particular operations? It always seems to me that they're the wrong way round - 'delete' sounds like a careful removal, whereas 'destroy' sounds like wanton removal without regard for the aftereffects. Are there legacy reasons for the choice?
Jon
Haha, I've always thought the same thing 
I'm guessing only David
knows for sure.
obliterate?
annihilate?
massacre?
decimate?
too much caffeine.
Jeff Pritchard wrote:
What does "destroy" check for and/or fix up that might get skipped by "delete"?
I struggled with this just a couple days ago and wound up apparently picking the wrong one since I couldn't find any documentation (as usual) for the difference. Just something about "instantiates it first"; and since I didn't particularly need to instantiate it, I chose "delete".
Every ActiveRecord object can have 'callbacks' associated with it. These let you attach behaviour to certain points in the object's lifecycle. For example, you could run validity checks on an object before it is created, or you could make it so that only objects that are in a certain state are allowed to be destroyed/deleted. Also, some of the built-in ActiveRecord facilities (such as :dependent => :whatever) internally make use of the callback system to do their dirty work.
When you use a 'destroy' method to delete an object or objects, ActiveRecord goes through the full process of creating the object in memory as an ActiveRecord object (AKA instantiating the object), checking all the callbacks and running them if appropriate, and deleting the row from the database.
In pseudo-ruby, calling User.destroy(1) does something like this:
user = User.find(1) user.run_all_before_destroy_callbacks user.execute_sql_to_delete_this_row user.run_all_after_destroy_callbacks
On the other hand, calling a 'delete' method doesn't bother with any of this. It simply executes a SQL statement to delete the row(s) from the database, and doesn't give any other bit of ActiveRecord a chance to get involved. So, calling User.delete(1) does something like this:
User.execute_sql_to_delete_row(1)
As a rule of thumb, I'd say you should always use 'destroy'. I'd only use 'delete' if I needed to for a specific performance optimisation, and if I was absolutely sure that the class in question had no callbacks or similar related behaviour attached to it.
Chris
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks