Strange behaviour with ActiveRecord has_many collections, Rails 4 compared to Rails 3

Hi All,

I have been told to post discussion based topic on here instead of the
GitHub Issues.

I thought this ‘could’ be a bug, but just need some clarification
really.
The issue I posted is here
https://github.com/rails/rails/issues/12597,
does anyone have any thoughts?

Again: Strange behaviour with ActiveRecord has_many collections, Rails 4 compared to Rails 3. · Issue #12597 · rails/rails · GitHub

Thanks a lot.

On Monday, October 21, 2013 11:28:22 AM UTC+1, Neil Williams wrote:

Again: Strange behaviour with ActiveRecord has_many collections, Rails 4 compared to Rails 3. · Issue #12597 · rails/rails · GitHub

Thanks a lot.

To be honest it feels to me like what you were using just happened to
work
by accident, because by default method_missing on the association sets
up a
scope and calls the method on the class. If this was indeed accidental
behaviour then the change could well be the side effect of another
change.
Using new in this way isn’t something I’ve come across in quite a few
years
of using rails.

Fred

Hi Fred,

Thanks for your reply.

“Using new in this way isn’t something I’ve come across in quite a few
years of using rails.”
How would you initialise a new Task object given you have the @story
instance available to you?

@task = Task.new(:story_id => @story.id) ?

If the above, I really don’t see the point of the new and build methods
for
a has_many association…

For a has_one association, I would be able to do:
@task = @story.build_task

So it makes no sense, that @task = @story.tasks.build doesn’t do the
same
thing… As ‘build’ seems to just be an alias of ‘new’.

Thanks.

On Monday, October 21, 2013 4:37:22 PM UTC+1, Neil Williams wrote:

I’ve always done @story.tasks.build(…)

The fact that this adds the built instance to the in memory collection
has
never been a problem for me

Fred

Hi Fred,

Thanks for this.

yes I can understand why it has never been a problem. It won’t be too
much
of a problem for us either, as the collection variable e.g. @tasks,
would
normally be filtered with .where() or be ordered with .order(),
therefore,
they would be different instances. But I logged it as a bug, because it
just doesn’t seem right.

I can’t think of any reason why one would want the built instance added
to
the in memory collection…

Anyway, I think I’ve been a bit cheeky on the Github issue, not sure if
I’m
going to get another response!

Thanks for your reply though.