Rails 4.0 - bring back in-place editing support for collection associations

[georgiev]

This PR is related to
#12140, #12213, 1a40be0 and #12227
Since personally I'm very unhappy with the way the resolution of these issues is heading, and I thing it's killing the fun in Rails and forces me to write awkward code - here goes my offer

[rafaelfranca]

I think I'm missing something. Are not the in-place edit, methods still deprecated in your PR?

[georgiev]

Not for the CollectionProxy - it overrides array_delegate().
I left the deprecation in the default implementation as I'm not aware of all usage scenarios.

[rafaelfranca]

I think you missunderstood. This behavior was changed by design. We choose to not support this in Rails 4.0 and we will not bring it back.

[rafaelfranca]

Thank you for your pull request.

[georgiev]

Can I see the discussion somewhere ?

[rafaelfranca]

Unfortunately no. It was in our private campfire room

[georgiev]

Can you tell In two words - why did you chose to do that?

[rafaelfranca]

But this change is on the CHANGELOG entry 0a6833b

[rafaelfranca]

Because it causes confusion where you think you are changing the relation/association and you actually is not. The database is still the same.

[georgiev]

Sorry but all that I can see is more awkward code instead has_many.select!{ my records } I'll have to do has_many = has_many.select{ my records } , the results is the same only more difficult to achieve.

[georgiev]

and with more array dupping

[rafaelfranca]

Yup, this is another thing we want to avoid. This kind of operation is not performatic if you have a huge set of data. If you want to do select you should be using the query interface, not the array methods.

[rafaelfranca]

But if you want to do in-place editing you still can:

has_many_array = has_many.to_a

has_many_array.select! { }

[georgiev]

Yea I know that but how can I tell back to the association that it should unlink some records when the owner is saved?, This hurts autosave cascading.

[rafaelfranca]

Using replace?

[georgiev]

As far as I see this is instant and will not bundle with owner save transaction. Am I wrong?

[rafaelfranca]

You can also set the association. page.comments = new_comments

[georgiev]

Which brings us exactly where we started - I'll have to use assignment to throw out some comments.

[rafaelfranca]

Yes. And it is fine. I don't see any problem on using it. The decision was already made and like I said we will not change it back since it introduce more confusion than feature.

We prefer to make the things explicit.

Thank you for the discussion.

[georgiev]

Ok - beer for all of you people!

Just a few final questions:
In the CHANGELOG I see WHAT is done but nothing about WHY?
Why should I write more code to achieve the same thing?
In application level terms - what is belongs_to - the object I belong to right?
What is has_one - the object that I have right?
What is has_many - a COLLECTION of objects that I have right?
If the above is right why is the has_many NOT acting as a collection (I don't really care if its Relation or Array)?
When is has_many acting as a collection and when it's not, which methods are available and which are not?
Should I always call to_a just to be sure that all collection methods are available?
If the above is true why don't you call it for me?
And how is duplicating the array for each and every array delegated method efficient by any means?
How has_many.build aligns with your concept of no in-place modifications?
If you want to make things explicit - why don't you drop the whole array delegation (it's inefficient anyway)? That's what will make things explicit.

Anyway it was really nice discussion.
Thank you too.

[rafaelfranca]

@georgiev These are good point. I'll ask the Core teams opinions on this subject.

[joshjordan]

@rafaelfranca "Because it causes confusion where you think you are changing the relation/association and you actually is not. The database is still the same."

^ Really? Who would think that? That's ridiculous.

You seem to be designing for people that have very little understanding of the system that they're working on, rather than the common case. Further, a single statement of warning in documentation should solve this problem. Someone would need to try it only once to understand. This direction seems so inconsistent with the entire concept of editing ActiveRecord objects in memory.

[rafaelfranca]

ridiculous

@joshjordan 💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙💚💛❤️💜💙