Hi everyone!

For those of you who are not noticed the in-place edit method for
collection associations are broken in the current rails release - 4.0.0,
and here's what is cooking in the rails master
https://github.com/rails/rails/commit/1a40be02113287d9a003f8224e91b9f623857f4b
and this https://github.com/rails/rails/pull/12227

In short: it looks like things like has_many.reject!{}, has_many.select!{},
has_many.delete_if{}, has_many.pop etc. will not work as of Rails 4.2.
I tried to get some answers about the motivation of this decision here
https://github.com/rails/rails/pull/12236 but i failed.

So to the question can someone please explain WHY is this happening?
Where is the "confusion" in the examples above?

PS.
I have read the CHANGELOG - it does not explain the motivation.
And please, I don't thing that "This behavior was changed by design. We
choose to not support this in Rails 4.0 and we will not bring it back" and "The
decision was already made and like I said we will not change it back since
it introduce more confusion than feature" are answers to my question at all.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/7c850665-fbcb-4741-9de5-b8b3e72dbc3b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • George Georgiev at Sep 21, 2013 at 6:18 am
    Monkey patch gem to revert to per rails 4 behaviour http://rubygems.org/gems/rails4-editable-collections

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/4e405f9a-f08c-4388-ac27-77a6cb0e0f9a%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Jones at Sep 23, 2013 at 2:54 pm

    On Tuesday, 17 September 2013 00:43:15 UTC-5, George Georgiev wrote:
    Hi everyone!

    For those of you who are not noticed the in-place edit method for
    collection associations are broken in the current rails release - 4.0.0,
    and here's what is cooking in the rails master
    https://github.com/rails/rails/commit/1a40be02113287d9a003f8224e91b9f623857f4b
    and this https://github.com/rails/rails/pull/12227

    In short: it looks like things like has_many.reject!{},
    has_many.select!{}, has_many.delete_if{}, has_many.pop etc. will not work
    as of Rails 4.2.
    I tried to get some answers about the motivation of this decision here
    https://github.com/rails/rails/pull/12236 but i failed.

    So to the question can someone please explain WHY is this happening?
    Where is the "confusion" in the examples above?
      Another related ticket: https://github.com/rails/rails/issues/12140

    The problem is that using (for instance) delete_if on a collection removes
    things from the in-memory version but doesn't persist the changes. It
    *can't* persist the changes, since the records have been removed from the
    association's list of records. This is EXACTLY the "confusion" referenced
    in the tickets.

    One of your examples in 12236 highlights this issue: these two code
    snippets (in Rails 3 or 4) do not do the same thing:

    post.comments.select! { |comment| comment.not_spam? }
    # => filters the array in-memory but does not unlink objects

    vs

    comments = post.comments.to_a
    comments.select! { |comment| comment.not_spam? }
    post.comments = comments
    # => unlinks comments that aren't in the filtered array

    --Matt Jones

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/18f8ba4e-29ec-4c04-863f-1ac857ef4e02%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Jordan at Sep 24, 2013 at 12:19 pm
    The justification for this change seems preposterous. Why would anyone
    think that, in the former example, the database has changed? The method
    called there is named "select!".

    This sounds like a case of a few people writing fragile code without any
    understanding of what they were doing or the systems they work on, and
    complaining about it. I suggested that a simple bit of documentation would
    solve the problem. It doesn't seem to make much sense to make this
    particular interface so inconsistent with the rest of ActiveRecord, which
    absolutely allows you to modify objects in memory.
    On Monday, September 23, 2013 9:59:52 AM UTC-4, Matt Jones wrote:


    On Tuesday, 17 September 2013 00:43:15 UTC-5, George Georgiev wrote:

    Hi everyone!

    For those of you who are not noticed the in-place edit method for
    collection associations are broken in the current rails release - 4.0.0,
    and here's what is cooking in the rails master
    https://github.com/rails/rails/commit/1a40be02113287d9a003f8224e91b9f623857f4b
    and this https://github.com/rails/rails/pull/12227

    In short: it looks like things like has_many.reject!{},
    has_many.select!{}, has_many.delete_if{}, has_many.pop etc. will not work
    as of Rails 4.2.
    I tried to get some answers about the motivation of this decision here
    https://github.com/rails/rails/pull/12236 but i failed.

    So to the question can someone please explain WHY is this happening?
    Where is the "confusion" in the examples above?
    Another related ticket: https://github.com/rails/rails/issues/12140

    The problem is that using (for instance) delete_if on a collection removes
    things from the in-memory version but doesn't persist the changes. It
    *can't* persist the changes, since the records have been removed from the
    association's list of records. This is EXACTLY the "confusion" referenced
    in the tickets.

    One of your examples in 12236 highlights this issue: these two code
    snippets (in Rails 3 or 4) do not do the same thing:

    post.comments.select! { |comment| comment.not_spam? }
    # => filters the array in-memory but does not unlink objects

    vs

    comments = post.comments.to_a
    comments.select! { |comment| comment.not_spam? }
    post.comments = comments
    # => unlinks comments that aren't in the filtered array

    --Matt Jones
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/95d1558b-1729-4015-93a5-d6d3bd84f57c%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • George Georgiev at Sep 25, 2013 at 5:48 am
    Thank you Matt!!
    Now I see my own confusion - I was convinced that these two snippets are
    identical in Rails 3 (Well, they are - JUST in MY case)

    When they do the same thing - when the collection contains only new records
    (hence no unlinking required).
    In all other cases in-place filtering doesn't work even in Rails 3 as you
    pointed out.

    But I still disagree that dropping the in-place methods (and breaking the
    Collection contract) is the best solution.

    Thank you once again for clarifying!!
    On Monday, September 23, 2013 4:59:52 PM UTC+3, Matt Jones wrote:


    On Tuesday, 17 September 2013 00:43:15 UTC-5, George Georgiev wrote:

    Hi everyone!

    For those of you who are not noticed the in-place edit method for
    collection associations are broken in the current rails release - 4.0.0,
    and here's what is cooking in the rails master
    https://github.com/rails/rails/commit/1a40be02113287d9a003f8224e91b9f623857f4b
    and this https://github.com/rails/rails/pull/12227

    In short: it looks like things like has_many.reject!{},
    has_many.select!{}, has_many.delete_if{}, has_many.pop etc. will not work
    as of Rails 4.2.
    I tried to get some answers about the motivation of this decision here
    https://github.com/rails/rails/pull/12236 but i failed.

    So to the question can someone please explain WHY is this happening?
    Where is the "confusion" in the examples above?
    Another related ticket: https://github.com/rails/rails/issues/12140

    The problem is that using (for instance) delete_if on a collection removes
    things from the in-memory version but doesn't persist the changes. It
    *can't* persist the changes, since the records have been removed from the
    association's list of records. This is EXACTLY the "confusion" referenced
    in the tickets.

    One of your examples in 12236 highlights this issue: these two code
    snippets (in Rails 3 or 4) do not do the same thing:

    post.comments.select! { |comment| comment.not_spam? }
    # => filters the array in-memory but does not unlink objects

    vs

    comments = post.comments.to_a
    comments.select! { |comment| comment.not_spam? }
    post.comments = comments
    # => unlinks comments that aren't in the filtered array

    --Matt Jones
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/3b603811-8d04-4d3e-a76e-707400ce2d97%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedSep 17, '13 at 6:10a
activeSep 25, '13 at 5:48a
posts5
users3
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase