After upgrading 3.0.4 -> 3.0.5 one of my tests now fails on an assertion like ''assert !@product.destroy''. This tests a :before_destroy callback which simply returns false to prevent deletion. I verified that the callback is firing and haven''t been able to locate a difference between what''s returned in the 3.0.4 and 3.0.5 source code. A console session shows destroyed? returning false as expected. Has this happened to anybody else? It''s a simple test so I''d expect others to have the same result if there''s an actual problem. Lighthouse shows a recent issue with before_destroy but it appears unrelated. -- 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 Mar 23, 2:19 pm, djangst <djangst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> After upgrading 3.0.4 -> 3.0.5 one of my tests now fails on an > assertion like ''assert !@product.destroy''. > > This tests a :before_destroy callback which simply returns false to > prevent deletion. I verified that the callback is firing and haven''t > been able to locate a difference between what''s returned in the 3.0.4 > and 3.0.5 source code. A console session shows destroyed? returning > false as expected. > > Has this happened to anybody else? It''s a simple test so I''d expect > others to have the same result if there''s an actual problem. > Lighthouse shows a recent issue with before_destroy but it appears > unrelated.Is this using a habtm association? There was a change to how destroy happens with those (which I personally think is broken) to do with when the before_destroy callbacks run relative to the clearing out of associated rows. It looks to me like a side effect of that change could be that the return value of destroy could change Fred -- 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.
Hey Fred, The model in question does have a HABTM association, but based on reading the ticket I thought it was unrelated because I don''t have a dependent destroy set up and am only operating on the parent. Maybe not. I had looked at the new and old versions of destroy() but it appeared they were returning the same value. destroy() calls freeze(). In a console session with a sample object frozen? returns false with my callback enabled, and true with it commented out, so that appears to be working. I guess I''d need to set up 3.0.4 again and check the output to see if it was returning a different (falsy) value... On Mar 23, 11:26 am, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Is this using a habtm association? There was a change to how destroy > happens with those (which I personally think is broken) to do with > when the before_destroy callbacks run relative to the clearing out of > associated rows. It looks to me like a side effect of that change > could be that the return value of destroy could change > > Fred-- 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.