I was surprised to see this redirect worked:
# FYI Project has_many Tasks, and Task belongs_to Project
# Task controller
def destroy
@task = Task.find(params[:id])
@task.destroy
flash[:notice] = "Successfully destroyed task."
redirect_to @task.project
end
I assume that clean up doesn''t happen until after destroy. Seems that
''project'' should be cached before @task.destroy or is it
actually safe
to use this way? I''d think this might be one of those places where
production might behave differently from development and test.
Rails 3.0.0.beta4
Ruby 1.8.7
--
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 23, 2010, at 8:28 AM, Dee wrote:> I was surprised to see this redirect worked: > > # FYI Project has_many Tasks, and Task belongs_to Project > > # Task controller > > def destroy > @task = Task.find(params[:id]) > @task.destroy > flash[:notice] = "Successfully destroyed task." > redirect_to @task.project > end > > I assume that clean up doesn''t happen until after destroy. Seems that > ''project'' should be cached before @task.destroy or is it actually safe > to use this way? I''d think this might be one of those places where > production might behave differently from development and test.Well, this is fine as long as you don''t have the :dependent => :destroy option set on the task/project relationship. You can destroy an object and still have access to it. You just can''t modify it, etc... it''s gone from the DB, but you''re "@task" object is still an object. If you call @task.frozen? it will return true which may/may-not be useful to you. -philip -- 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks, Philip, for a thorough response. Of course you''re right. I see your point with the dependent_destroy -- but task is the dependent in the relationship so I think I''m okay. On Jul 23, 12:03 pm, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org> wrote:> On Jul 23, 2010, at 8:28 AM, Dee wrote: > > > > > I was surprised to see this redirect worked: > > > # FYI Project has_many Tasks, and Task belongs_to Project > > > # Task controller > > > def destroy > > @task = Task.find(params[:id]) > > -G82Eqi2FH56v9pIUa/Yw3w@public.gmane.org > > flash[:notice] = "Successfully destroyed task." > > redirect_to @task.project > > end > > > I assume that clean up doesn''t happen until after destroy. Seems that > > ''project'' should be cached before @task.destroy or is it actually safe > > to use this way? I''d think this might be one of those places where > > production might behave differently from development and test. > > Well, this is fine as long as you don''t have the :dependent => :destroy option set on the task/project relationship. > > You can destroy an object and still have access to it. You just can''t modify it, etc... it''s gone from the DB, but you''re "@task" object is still an object. > > If you call @task.frozen? it will return true which may/may-not be useful to you. > > -philip-- 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.