Bug in commit 5efb1503dd88b59fe491dade92790c3f06293445

Dear rails core developers.

I highly value your work on the rails framework.

I recently upgraded rails fro 2.3.5 to 2.3.8, and my tests revealed a
problem.

I switch to git 2-3-stable branch and used git bisect to isolate the
first bad commit, and it showed to be
5efb1503dd88b59fe491dade92790c3f06293445

The problem is that using {:_destroy => "1"} on a nested (has_many)
model has no effect after the bad commit.

Can someone please help me write a minimal test (along the other AR
tests) for illustrating the problem and to prevent this from happen
again in the future.

Jarl

I ran into this same issue yesterday, but have been unable to come up with a failing test case yet. In our case, the issue was that ActiveRecord handled the nested attributes properly and set the "marked_for_destruction" flag on the instance in the association proxy's target. At this point the association's "loaded" flag was still false. Subsequent to that, before saving, our application iterated over the members of the association, causing it to "load" and replace the instance in the target with an instance from the database, which is crucially missing the proper "marked_for_destruction" flag.

We have temporarily worked around it by forcing the association to load before setting the attributes.

It turns out that this affects both modifications as well as requests to destroy nested models.

I've added a ticket with failing tests and a summary of the problem. I'm happy to prepare a patch with a "fix" if I can get some guidance on what the expected behavior ought to be here.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4766

Cheers,
Luke

See test at:

https://rails.lighthouseapp.com/projects/8994/tickets/4766-nested_attributes-fails-to-updatedestroy-when-association-is-loaded-between-setting-attributes-and-saving-parent

Cheers,
Lawrence