Rails core - Jun 2010 - 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


-- 
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.

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.

On Jun 4, 2010, at 8:28 AM, Jarl Friis wrote:
> 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
> 
> 
> -- 
> 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.
> 
--
Luke Melia
http://www.lukemelia.com/



-- 
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.

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

On Jun 4, 2010, at 8:39 AM, Luke Melia wrote:
> 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.
> 
> On Jun 4, 2010, at 8:28 AM, Jarl Friis wrote:
> 
>> 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
>> 
>> 
>> -- 
>> 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.
>> 
> 
> --
> Luke Melia
> http://www.lukemelia.com/
> 
> 
> 
> -- 
> 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.
> 
--
Luke Melia
http://www.lukemelia.com/



-- 
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.

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
> 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
>
>
>   
-- 
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.