#4766 nested_attributes fails to update/destroy when association is loaded between setting attributes and saving parent - 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.

#4766 ✓duplicate

nested_attributes fails to update/destroy when association is loaded between setting attributes and saving parent

Reported by Luke Melia | June 4th, 2010 @ 04:47 PM | in 2.3.10

Commit 5efb1503dd88b59fe491dade92790c3f06293445 introduced behavior to avoid loading all records of a has_many association when using nested_attributes. This commit causes surprising behavior: if you trigger a load of the association after setting the attributes but before saving, the instances with the changes/mark_for_destruction will be replaced with fresh instances from the DB, thereby losing the desired changes.

I'm not sure if this would be considered a bug, but it is changed behavior from 2.3.5 and is silent and surprising.

I've attached a patch with failing tests, but I am looking for ideas for a solution. In my app, I have hacked around it by forcing the load of the relevant associations before assigning attributes.

Note: This issue was introduced on the rails-core list here: http://groups.google.com/group/rubyonrails-core/browse_thread/threa...

nested_attributes_destroy_failing_test.diff 2.2 KB

Comments and changes to this ticket

You flagged this item as spam.
Luke Melia June 4th, 2010 @ 04:49 PM
- Tag set to “association_proxy, nested_attributes_for”
You flagged this item as spam.
Luke Melia June 4th, 2010 @ 04:50 PM
- Tag changed from “association_proxy, nested_attributes_for” to “2.3.8, association_proxy, nested_attributes_for”
Pratik June 4th, 2010 @ 10:54 PM
- Milestone cleared.
Pratik June 4th, 2010 @ 10:54 PM
- no changes were found...
Pratik June 4th, 2010 @ 10:54 PM
- Assigned user set to “Pratik”
You flagged this item as spam.
David North June 4th, 2010 @ 11:05 PM
I think because of this commit, I'm having a related problem where records in a has_many association are not updated at all unless the collection is first loaded from the database.

The following worked before 2.3.8:
```
@order.update_attributes {"line_items_attributes"=>{"0"=>{"quantity"=>"2", "order_id"=>"1069267031", "id"=>"1070870199", "variant_id"=>"215054540"}}}
```
It works now if I do this first:
```
@order.line_items(true)
```
You flagged this item as spam.
Sharad Jain June 5th, 2010 @ 12:12 AM
This also happens in rails 2.3.8
Rizwan Reza June 6th, 2010 @ 09:08 AM
- Milestone set to “2.3.9”
You flagged this item as spam.
Jarl Friis June 7th, 2010 @ 11:19 AM
@David North: You can figure out if the commit mentioned is the first bad commit using git bisect. Here is a rough description of how to do this: 0) open two terminals (one in your rails project, and one in your git version of rails)
1) in terminal 1: Change your project to use your git version of rails:
```
ln -s /your/path/to/rails vendor/rails
```
2) in terminal 2: do a git bisect (see http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html)
```
git bisect v2.3.8 v2.3.5
```
3) in terminal 1: test if the rails version is good or bad
```
ruby -I test test/integration/test_that_fails_in_2_3_8.rb --name "test: failing test"
```
4) in terminal 2: use git bisect to determine next commit depending on result of step 3
```
git bisect [good|bad]
```
5) repeat step 3-4 until step 4 reveals the first bad commit.

Jarl
You flagged this item as spam.
Jarl Friis June 7th, 2010 @ 12:29 PM
I highly appreciate that milestone is 2.3.x and not 3.x, thanks.
You flagged this item as spam.
Pete Deffendol June 7th, 2010 @ 04:03 PM
Duplicate of #4642?
You flagged this item as spam.
James Le Cuirot June 7th, 2010 @ 09:18 PM
Yes, this is the same as my issue. I have proposed a solution that does not involve undoing the commit that broke it.
You flagged this item as spam.
James Le Cuirot June 9th, 2010 @ 01:53 PM
This has now been fixed. See the other ticket.
Jeremy Kemper August 30th, 2010 @ 02:28 AM
- Milestone changed from “2.3.9” to “2.3.10”
- Importance changed from “” to “Low”
[bulk edit]
Jeff Kreeftmeijer October 10th, 2010 @ 09:01 AM
- State changed from “new” to “duplicate”
Duplicate of #4642