>
> No. Destroy has to instantiate each object prior to actually removing it
> from the database in order to run any before/after destroy call backs.
>
> You can speed things up if you don't need this by tweaking the :dependent
> option to has_many so that it will simply use SQL's DELETE on the child
> objects... but that of course won't run any callbacks (your own, or Rail's
> counter cache, etc.)
Actually it doesn't HAVE to instantiate them if it can query the
relationships in a meaningful matter. Of course we know that it CAN
query those relationships and calculate what has to be deleted.
I did this....
id_list = Model.select(:id).where(whereclause)..map { |r| r.id }.join(',')
This gives you a list of comma delimited ids
ActiveRecord::Base.transaction do
Children.delete_all('parent_id in (#{id_list})")
Children2.delete_all('parent_id in (#{id_list})")
Children3.delete_all('parent_id in (#{id_list})")
end
In my case I had about a half a dozen children.
The delete time for my records went from four minutes to under 30
seconds. That's a pretty big gain. Of course I had to hand code my
relationships and if I add something new I will have to modify my
method. It would be really nice if somebody way smarter than me
implemented this into AR.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
