Bug in commit 5efb1503dd88b59fe491dade92790c3f06293445

1 view
Skip to first unread message

Jarl Friis

unread,
Jun 4, 2010, 8:28:46 AM6/4/10
to rubyonra...@googlegroups.com, Pratik Naik
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


Luke Melia

unread,
Jun 4, 2010, 8:39:40 AM6/4/10
to rubyonra...@googlegroups.com, Pratik Naik
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.

> --
> 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 rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>

--
Luke Melia
http://www.lukemelia.com/

Luke Melia

unread,
Jun 4, 2010, 11:50:17 AM6/4/10
to rubyonra...@googlegroups.com, Pratik Naik
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

Lawrence Pit

unread,
Jun 6, 2010, 4:04:19 AM6/6/10
to rubyonra...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages