Rails core - Mar 2011 - 909588d causes breakage if foreign keys are used

909588d (for https://rails.lighthouseapp.com/projects/8994/tickets/6191)
reordered how destroy works with has and belongs to many.

The intent of the change is to ensure that before_destroy is called before any
destroying happens which sounds right, but does it by removing the join table
records after the owner is destroyed. This breaks all of my foreign key backed
habtm associations since the foreign key won''t allow deleting the owner
while there are still join records pointing at it.

Was this an oversight? Having all the before_destroy callbacks run first
definitely feels right, but I''d much prefer that this didn''t
clash with foreign keys (even if the default rails position isn''t to
use database constraints)

Fred

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Yes, it is a bug.

Here is a very simply fix that considers both your scenario and the
one in the original patch: https://gist.github.com/883459

Once we have a test case, I can apply and get this fixed. :D Thanks
for reporting!

On Mar 5, 6:40 pm, Frederick Cheung <frederick.che...@gmail.com>
wrote:
> 909588d (forhttps://rails.lighthouseapp.com/projects/8994/tickets/6191)
reordered how destroy works with has and belongs to many.
>
> The intent of the change is to ensure that before_destroy is called before
any destroying happens which sounds right, but does it by removing the join
table records after the owner is destroyed. This breaks all of my foreign key
backed habtm associations since the foreign key won''t allow deleting
the owner while there are still join records pointing at it.
>
> Was this an oversight? Having all the before_destroy callbacks run first
definitely feels right, but I''d much prefer that this didn''t
clash with foreign keys (even if the default rails position isn''t to
use database constraints)
>
> Fred
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Note: it seems google ignored my original post. Sorry if it ends up
twice.

Yes, it is a bug.

Here is a very simple fix that considers your scenario and the one in
the original patch: https://gist.github.com/883459

If you can provide a failing test, we can commit the fix + tests
straight away. :D Thanks for reporting!

On Mar 5, 6:40 pm, Frederick Cheung <frederick.che...@gmail.com>
wrote:
> 909588d (forhttps://rails.lighthouseapp.com/projects/8994/tickets/6191)
reordered how destroy works with has and belongs to many.
>
> The intent of the change is to ensure that before_destroy is called before
any destroying happens which sounds right, but does it by removing the join
table records after the owner is destroyed. This breaks all of my foreign key
backed habtm associations since the foreign key won''t allow deleting
the owner while there are still join records pointing at it.
>
> Was this an oversight? Having all the before_destroy callbacks run first
definitely feels right, but I''d much prefer that this didn''t
clash with foreign keys (even if the default rails position isn''t to
use database constraints)
>
> Fred
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Mar 23, 6:18 pm, José Valim <jose.va...@gmail.com>
wrote:
> Note: it seems google ignored my original post. Sorry if it ends up
> twice.
>
> Yes, it is a bug.
>
> Here is a very simple fix that considers your scenario and the one in
> the original patch:https://gist.github.com/883459
>
Looks good!
> If you can provide a failing test, we can commit the fix + tests
> straight away. :D Thanks for reporting!
>
I''ll see what I can cook up. I assume it would be preferable to come
up with a test that enshrines the precise sequencing without actually
requiring the table to have foreign keys in place

Fred
> On Mar 5, 6:40 pm, Frederick Cheung <frederick.che...@gmail.com>
> wrote:
>
>
>
> > 909588d
(forhttps://rails.lighthouseapp.com/projects/8994/tickets/6191) reordered how
destroy works with has and belongs to many.
>
> > The intent of the change is to ensure that before_destroy is called
before any destroying happens which sounds right, but does it by removing the
join table records after the owner is destroyed. This breaks all of my foreign
key backed habtm associations since the foreign key won''t allow
deleting the owner while there are still join records pointing at it.
>
> > Was this an oversight? Having all the before_destroy callbacks run
first definitely feels right, but I''d much prefer that this
didn''t clash with foreign keys (even if the default rails position
isn''t to use database constraints)
>
> > Fred
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 3/24/2011 2:33 PM, Frederick Cheung wrote:
>
>
> On Mar 23, 6:18 pm, José Valim<jose.va...@gmail.com>  wrote:
>> Note: it seems google ignored my original post. Sorry if it ends up
>> twice.
>>
>> Yes, it is a bug.
>>
>> Here is a very simple fix that considers your scenario and the one in
>> the original patch:https://gist.github.com/883459
>>
>
> Looks good!
Since you guys are already working on it can I also get some feedback on 
this comment 
https://rails.lighthouseapp.com/projects/8994/tickets/5674-regression-habtm-deletion-fails-when-join-table-has-foreign-keys#ticket-5674-10
?

(To repeat: patch solves the problem with the DB keys but any 
before_destroy callback on the model with HABTM assoc will see that 
assoc already emptied when fired)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Mar 24, 11:48 am, Evgeniy Dolzhenko <dolze...@gmail.com>
wrote:
> On 3/24/2011 2:33 PM, Frederick Cheung wrote:
>
>
>
> > On Mar 23, 6:18 pm, Jos Valim<jose.va...@gmail.com>  wrote:
> >> Note: it seems google ignored my original post. Sorry if it ends
up
> >> twice.
>
> >> Yes, it is a bug.
>
> >> Here is a very simple fix that considers your scenario and the one
in
> >> the original patch:https://gist.github.com/883459
>
> > Looks good!
>
> Since you guys are already working on it can I also get some feedback on
> this
commenthttps://rails.lighthouseapp.com/projects/8994/tickets/5674-regression...
> ?
>
We should be ok there - The ticket/commit i linked to earlier adds
tests ensuring that before_destroy fires before any destroying happens
(although unfortunately in a way that introduces problems when foreign
keys are in use). José''s proposed fix won''t break that

Fred
> (To repeat: patch solves the problem with the DB keys but any
> before_destroy callback on the model with HABTM assoc will see that
> assoc already emptied when fired)
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Mar 24, 11:33 am, Frederick Cheung <frederick.che...@gmail.com>
wrote:
>
> I''ll see what I can cook up. I assume it would be preferable to
come
> up with a test that enshrines the precise sequencing without actually
> requiring the table to have foreign keys in place
>
I''ve put something up at
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6629-habtm-destroy-deletes-record-before-associated-records

Fred

> Fred
>
>
>
> > On Mar 5, 6:40 pm, Frederick Cheung <frederick.che...@gmail.com>
> > wrote:
>
> > > 909588d
(forhttps://rails.lighthouseapp.com/projects/8994/tickets/6191) reordered how
destroy works with has and belongs to many.
>
> > > The intent of the change is to ensure that before_destroy is
called before any destroying happens which sounds right, but does it by removing
the join table records after the owner is destroyed. This breaks all of my
foreign key backed habtm associations since the foreign key won''t allow
deleting the owner while there are still join records pointing at it.
>
> > > Was this an oversight? Having all the before_destroy callbacks
run first definitely feels right, but I''d much prefer that this
didn''t clash with foreign keys (even if the default rails position
isn''t to use database constraints)
>
> > > Fred
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.