#5674 Regression: HABTM deletion fails when join table has foreign keys - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#5674 ✓committed

Regression: HABTM deletion fails when join table has foreign keys

Reported by Steve Purcell | September 21st, 2010 @ 11:19 AM

Given models One and Two, where One declares "has_and_belongs_to_many :twos", it's no longer possible to delete an instance of One if there are corresponding rows in the join table (ones_twos) and that join table has a foreign key on one_id.

In Rails < 3, the rows in the join table would be deleted before the parent object, but in 3.0 the join table rows appear to be deleted afterwards, and so any foreign key will block the deletion of the parent object -- dropping the foreign keys makes everything work, but this is an extremely undesirable workaround.

There's no obvious option for habtm to fix this behavior, and no mention of related changes in the Rails 3 Guides, so I can only guess that this is a regression.

The problem presents itself with both PostgreSQL 8.4 and 9.0, but would also presumably affect other DBs with foreign key support.

Comments and changes to this ticket

You flagged this item as spam.
Steve Purcell September 21st, 2010 @ 11:39 AM
The attached patch to schema.rb causes the relevant tests to fail with the problem as described.
- 0001-add-foreign-key-on-developers_projectsdeveloper_id.patch 1020 Bytes
You flagged this item as spam.
gnufied September 21st, 2010 @ 07:10 PM
Verified. Problem exists. A quick workaround is, to have ON DELETE CASCADE on such foreign keys.
You flagged this item as spam.
Steve Purcell September 21st, 2010 @ 07:54 PM
Indeed, though it's generally recommended to avoid ON DELETE CASCADE, since records can disappear without Rails knowing. For example, adding ON DELETE CASCADE to developers_projects breaks 2 cases in NestedScopingTest.
You flagged this item as spam.
gnufied September 21st, 2010 @ 09:03 PM
- Tag changed from “3.0, activerecord, habtm” to “3.0, activerecord, habtm, patch”
Attached patch fixes the problem and updates the failing test cases to accomodate the new behavior.
- 5674_habtm_destroy.patch 1.9 KB
Aaron Patterson September 21st, 2010 @ 10:02 PM
- State changed from “new” to “committed”
- Importance changed from “” to “Low”
I've committed this, thanks!
You flagged this item as spam.
Steve Purcell September 22nd, 2010 @ 10:47 AM
Cool, thanks! -- will that fix get into 3.0.1? I don't see it in the 3-0-stable branch, but maybe the plan is to merge master for that release.
Aaron Patterson September 22nd, 2010 @ 04:37 PM
No! I made a mistake. I was going to merge to the 3-0-stable branch, but I forgot! Thanks for reminding me. It should be on the 3-0-stable branch now. Thanks!
You flagged this item as spam.
Steve Purcell October 4th, 2010 @ 10:43 AM
In case it helps anyone while we wait for 3.0.1, I've posted the monkey patch initializer I'm using to work around this issue here:

http://gist.github.com/605268
You flagged this item as spam.
Evgeniy Dolzhenko November 23rd, 2010 @ 12:09 PM
The problem with the patch that was committed is that now before_destroy callbacks on the models with HABTM associations don't see the corresponding associations. For example if you wanted to prevent models referenced by HABTM from being destroyed you can't do that with before_destroy callback any longer.
You flagged this item as spam.
Hemant Kumar November 23rd, 2010 @ 12:25 PM
Can you get a test case attached, I will see what I can do to fix the problem.